Prefix Delegation Protocol Selection

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 DraftsDHCPv6-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 DraftsDHCPv6-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 DraftsNEMO-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 DraftsNEMO-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 HAddrs
• 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?