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

2. Presentation Outline Problem Statement and Overview Problem Statement and Overview NEMO Drafts NEMO Drafts Other Reference Documents Other Reference Documents Working Group Discussion and Conclusions Working Group Discussion and Conclusions MEXT Charter Items MEXT Charter Items Questions 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? 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 Lifetime could be long-term, or for the session We could be dealing with the consumer case, or the fully- enabled router case 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 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 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 Submitted 6/2003 Uses existing DHCPv6 infrastructure, and Prefix Delegation option as defined in RFC 3633 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 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 HA must act as DR for MR but can be RA for AR can also act as DR 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 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 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? 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 Submitted 10/2004 Proposes new BU bit, BAck bit, and three BU options 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 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 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 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 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 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 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 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 Message flow is optimized to improve mobility aspects of the protocol No need to deploy DHCPv6-based infrastructure No need to deploy DHCPv6-based infrastructure Authentication is included as part of MIP/NEMO protocol flow Authentication is included as part of MIP/NEMO protocol flow Back-end can be supported by HA and provided with a common NEMO interface 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 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. 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. 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? Why not a DHCPv6-based solution? Please see the draft, section 4.4 Please see the draft, section 4.4

8. Other Reference Documents RFC 3633 – DHCPv6 Prefix Delegation Option RFC 3633 – DHCPv6 Prefix Delegation Option RFC 3769 – Requirements for IPv6 Prefix Delegation RFC 3769 – Requirements for IPv6 Prefix Delegation draft-sarikaya-16ng-prefix-delegation-02 draft-sarikaya-16ng-prefix-delegation-02 DHCPv6 prefix delegation in 802.16 networks DHCPv6 prefix delegation in 802.16 networks draft-sarikaya-netlmm-prefix-delegation-01 draft-sarikaya-netlmm-prefix-delegation-01 DHCPv6 prefix delegation in PMIPv6 DHCPv6 prefix delegation in PMIPv6 draft-sarikaya-dime-prefix-delegation-ps-00 draft-sarikaya-dime-prefix-delegation-ps-00 Using AAA (diameter) to manage prefix mgmt for backend Using AAA (diameter) to manage prefix mgmt for backend A couple of expired drafts on ICMPv6-based prefix delegation 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. NEMO-based PDel and DHCPv6-based PDel were accepted as working group items. Neither document proceeded to RFC Neither document proceeded to RFC Solicitation for implementor feedback did not yield much input Solicitation for implementor feedback did not yield much input Pushback on bringing two documents to the IESG 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 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 Recent discussion on MEXT ML on this topic

10. MEXT Charter Items Deliverable: Deliverable: (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Milestone: Milestone: Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard 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? 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? 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? 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 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? 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? What should be said about AAA managing address space, if anything?