1 / 11

Prefix Delegation Protocol Selection

Prefix Delegation Protocol Selection. T.J. Kniveton MEXT Working Group IETF 70 - December ’07 - Vancouver. Presentation Outline. Problem Statement and Overview NEMO Drafts Other Reference Documents Working Group Discussion and Conclusions MEXT Charter Items Questions.

idola
Download Presentation

Prefix Delegation Protocol Selection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Prefix DelegationProtocol Selection T.J. Kniveton MEXT Working Group IETF 70 - December ’07 - Vancouver

  2. Presentation Outline • Problem Statement and Overview • NEMO Drafts • Other Reference Documents • Working Group Discussion and Conclusions • MEXT Charter Items • Questions

  3. Problem Statement and Overview • If your Mobile Router is not statically pre-configured, how can you request and receive a prefix for your mobile network? • Lifetime could be long-term, or for the session • We could be dealing with the consumer case, or the fully-enabled router case • Consider the implications of a host auto-configuration environment, and of a managed, stateful address configuration environment • Note: Autoconf is now considering a similar issue for prefix delegation in connected/standalone MANETs

  4. NEMO Drafts:DHCPv6-based Prefix Del. (1) • Submitted 6/2003 • Uses existing DHCPv6 infrastructure, and Prefix Delegation option as defined in RFC 3633 • HA acts as Delegating Router or DHCPv6 Relay Agent and MR acts as Requesting Router • HA must act as DR for MR but can be RA for • AR can also act as DR

  5. NEMO Drafts:DHCPv6-based Prefix Del. (2) • The HA and MR exchange DHCPv6PD protocol messages through the tunnel, using link-local multicast and unicast addresses • The tunnel acts as the link labeled “DSL to subscriber premises” from DHCPv6PD specification • Provides a starting point for designing a DHCPv6-based solution.. but does it provide enough details for an implementation?

  6. NEMO Drafts:NEMO-based Prefix Del. (1) • Submitted 10/2004 • Proposes new BU bit, BAck bit, and three BU options • The HA is required to be involved in authenticating and authorizing MNPs as it is for HAddrs--but more important here due to properties of routing prefixes • Idea: IPv6 networks are designed for autonomy and mobility. A “chunk” of v6 prefix space can be delegated to the HA one time, or managed by a routing protocol, and the HA will manage the prefixes along with mobility for consumer devices • Consistent with routing protocols and address auto-configuration. Simple MRs can be implemented that are not required to be Requesting Routers and connect to DHCPv6 infrastructure to operate. Idea: HA handles complexity and flows are optimized to provide complete prefix info • There is not necessarily a need to run a pool of servers that actively manage the address space. It can be a function of the HA

  7. NEMO Drafts:NEMO-based Prefix Del. (2) • Allows delegation of prefixes from HA to MR on a temporary or permanent basis • Allows a MR to request a full list of prefixes. Bootstrapping, expired prefixes, newly allocated prefixes, newly allocated prefixes, prefix life association with the binding lifetime are supported by this approach • Prefix Delegation messages are included in normal NEMO protocol flow, with additional flags defined • Message flow is optimized to improve mobility aspects of the protocol • No need to deploy DHCPv6-based infrastructure • Authentication is included as part of MIP/NEMO protocol flow • Back-end can be supported by HA and provided with a common NEMO interface • Assumes that HA is tied into back-end infra, or has been assigned a super-prefix, just as it has already obtained prefix(es) for HAddr’s • Routing protocols, AAA backend, DHCPv6 can be used. • Bottom line is that HA is considered part of the routing infrastructure and is able to request/communicate prefix routing info for the MRs. This is the basic assumption. • Why not a DHCPv6-based solution? • Please see the draft, section 4.4

  8. Other Reference Documents • RFC 3633 – DHCPv6 Prefix Delegation Option • RFC 3769 – Requirements for IPv6 Prefix Delegation • draft-sarikaya-16ng-prefix-delegation-02 • DHCPv6 prefix delegation in 802.16 networks • draft-sarikaya-netlmm-prefix-delegation-01 • DHCPv6 prefix delegation in PMIPv6 • draft-sarikaya-dime-prefix-delegation-ps-00 • Using AAA (diameter) to manage prefix mgmt for backend • A couple of expired drafts on ICMPv6-based prefix delegation

  9. Working Group Discussion and Conclusions • NEMO-based PDel and DHCPv6-based PDel were accepted as working group items. • Neither document proceeded to RFC • Solicitation for implementor feedback did not yield much input • Pushback on bringing two documents to the IESG • Because of lack of feedback between the solutions, we did not advance one draft or the other • Recent discussion on MEXT ML on this topic

  10. MEXT Charter Items • Deliverable: • (B.3) Finish working group documents that are currently in process, andsubmit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. • Milestone: • Mar 2008  Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard

  11. Questions • How does MEXT want to reconcile the two NEMO working group drafts? • Do we want to assume that DHCPv6 will be present whenever prefixes are delegated? Is this the only way to scale HAs? • How far do you want to go with describing the system in these drafts? • If NEMO Prefix Del draft is a starting point, do you want to consider the back-end mechanism further? How far up the food chain? • If DHCPv6 is assumed, do you want to extend DHCPv6 to allow for additional NEMO-specific features, or do you want to drop some of the features in NEMO Prefix Del? • What should be said about AAA managing address space, if anything?

More Related