Subject: Re: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)

From: <[email-masked]>
Date: Sat, 27 Feb 2010 23:29:21 +0100

Ole,

Thank you for your attention.

Yes, number of messages is not the issue. However, with DHCPv6 PD the DHCPv6 server has to identify the RR, while in stateless the same ISP prefix could be communicated to all requesters. Nevertheless, your proposal is very interesting and we need to think about it. In a way there could be very lightweight DR at the gateway, right?

Have you seen also http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00 ? With DHCPv6 PD there's the issue of not being able to use one /64 on the WAN from the delegated space. On the other hand, not having a global /64 prefix on the WAN at all (unnumbred model) probably would be too big change for the 3GPP. Any thoughts about this issue?

Binding to L2 would indeed mean that, unless somehow kept the same during cellular network reconnection e.g. after unexpected network disconnect (NEMO is then for true network mobility..). I'll note this.

Best regards,

Teemu

----- Original message -----
> 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
>
>
> On Fri, Feb 26, 2010 at 12:48 PM,  <[email-masked]<mailto:[email-masked]>> wrote:
> > 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 23:56:06 +0100

Teemu,

> Yes, number of messages is not the issue. However, with DHCPv6 PD the DHCPv6 server has to identify the RR, while in stateless the same ISP prefix could be communicated to all requesters. Neverthel…

indeed. only difference is that you compute the prefix on the DR instead of at the RR.

> Have you seen also http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00 ? With DHCPv6 PD there's the issue of not being able to use one /64 on the WAN from the delegated space. On the other…

I think this violates the contract the RR has with the DR. you cannot delegate / aka give something to someone and then take back a bit of it. even though many managers delegate this way. ;-)

you could perhaps resolve this by making a modified PD option which carry a representation of the address block which allows for this.

or you could just split the block in two. e.g the route on the DR is a /55, you delegate the bottom /56 and you use the top one for the linknet /64.

cheers,
Ole

---

From: <[email-masked]>
Date: Sun, 28 Feb 2010 17:13:15 +0100

Ole,

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]] On Behalf Of ext Ole
> Troan
> Sent: 28. helmikuuta 2010 00:56
> To: Savolainen Teemu (Nokia-D/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Stateless Prefix Delegation I-D updated (draft-savolainen-
> stateless-pd)
>
> I think this violates the contract the RR has with the DR. you cannot
> delegate / aka give something to someone and then take back a bit of
> it. even though many managers delegate this way. ;-)
> 
> you could perhaps resolve this by making a modified PD option which
> carry a representation of the address block which allows for this.

But that is not backwards compatible..
 
> or you could just split the block in two. e.g the route on the DR is a
> /55, you delegate the bottom /56 and you use the top one for the
> linknet /64.

I thought of this as well, but it creates some waste... but maybe that could be mitigated by setting up the environment so that legacy RFC3633 compliant RR's would get half of the block given to those RRs that support the new option?

I.e. (3GPP) network policy could allocate e.g. /56 for a subscription, and if the subscriber is using legacy equipment he gets just /57, but if new equipment supporting new option then he would get /56 minus one /64?

Best regards,

Teemu