Subject: [3gv6] Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)

From: <[email-masked]>
Date: Fri, 26 Feb 2010 12:48:18 +0100

Hi,

We have updated the Stateless IPv6 Prefix Delegation draft with the following significant changes (in addition to various minor changes):

* Describing better that GTP TEID or GRE Key or similar could be used to construct the delegated prefix 

* Describing address space waste mitigation ways: dedicated APN (in 3GPP), and emphasizing need to optimize the size of the delegated prefixes

* Aggregating prefixes so that the /64 of the WAN interface (e.g. used for PDP context) is now part of the shorter-than-/64 prefix allocated to a node. I.e. a node may be allocated, for example, a single /60, of which one /64 is taken for WAN link by the gateway, leaving the rest for the node to use for downstream advertisement/delegation purposes

* Added a note that while possible, it may not be feasible, to delegate prefixes from different subnets (possible if one configures multiple ISP prefixes, but that would increase address space consumption even more)

------
http://www.ietf.org/id/draft-savolainen-stateless-pd-01.txt

Abstract:
This document describes an automatic and stateless IPv6 prefix delegation solution for IPv6-only and dual-stack access networks.
The solution builds on automatic delegation mechanism defined by 6RD, but is suitable for IPv6-only networks, including those that have not deployed stateful DHCPv6.  The described stateless approach essentially exchanges the complexity of the stateful prefix delegation to increased consumption of IPv6 address space and less flexible properties.
------                                                                            

All comments are welcome.

Best regards,

Teemu

---

From: Ole Troan <[email-masked]>
Date: Sat, 27 Feb 2010 13:13:13 +0100

Teemu,

note, that I'm probably biased since I was one of the co-authors of RFC3633. ;-)

am I interpreting the motivation of this draft correctly if I say that
you aren't concerned about the 2 or 4 packet DHCPv6 exchange between
the RR and the DR, but rather about the DHCP binding state and
resulting DHCP backend infrastructure?

if that is correct, couldn't you still run DHCP PD, but the prefixes
handed out are on the DR generated based on the other identifiers
described in your draft? then you don't need any further DHCP
infrastructure, changes on the RR or any new protocol machinery
between the RR and DR.

a delegated prefix is expected to have a 'reasonable' lifetime. rapid
renumbering or some would say renumbering at all is problematic. if
you bind a prefix to given L2 identifiers, doesn't that mean that you
will renumber every time your connection to the network changes?

cheers,
Ole