Subject: Questions about rfc2464 IPv6 over Ethernet

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 17:56:43 +0100

Dear 6MANers,

May I comment on two things about rfc2464 IPv6 over EThernet.

> 4.  Stateless Autoconfiguration

I think a better title for this would be "Forming an IID for Ethernet".
  Because that's what the majority of the text of the section describes.

And because it sounds too much as "Stateless Address Autoconfiguration"
described in rfc4862, which is much more than just forming an IID, and
has message exchanges.

>    An IPv6 address prefix used for stateless autoconfiguration [ACONF]
>    of an Ethernet interface must have a length of 64 bits.

I disagree with this.  There's an implementation of SLAAC over Ethernet 
whose prefix can be shorter than 64 and works ok.  I suppose there's at 
least another similar implementation.

Any thoughts on these two aspects?

Thanks,

Alex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 18 Feb 2009 11:02:26 -0800

At Wed, 18 Feb 2009 17:56:43 +0100,

> least another similar implementation.

I don't understand the logic.  Simply because there's an
implementation that doesn't follow the standard cannot be a reason for
changing the standard.  If we really want to do that, there should be a
clearer and stronger reason.

The pros and cons on the fixed prefix length for stateless
autoconfiguration had been discussed to death, and as far as I
remember the attempt to change the fixed length has never convinced
the community.  I'm not necessarily objecting to another attempt by
pointing it out, but I suspect we'll all just waste time by repeating
the same discussion again (ending up no change).

Out of curiosity, btw, what's the implementation that uses a shorter
prefix (or more essentially in this context, a larger interface
identifier), and for what does it use the larger IFID space?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Feb 2009 14:03:12 -0500

Hi Alex,

>  Because that's what the majority of the text of the section describes.

An IPv6 over foo document needs to define two parameters for SLAAC.

* IID formation
* DAD params (mainly DupAddrDetectTransmits)

RFC2464 defines the former while leaving the latter undefined and hence 
using the default(1). So, I think it is defining SLAAC parameters. I do 
not have a strong preference, but the way I see it, the current title 
looks fine. It is certainly not worth a bis :-)

> least another similar implementation.

Given that the EUI-64 identifier as described in RFC2464 is 64 bits long 
and the following statement in RFC4862

"If the sum of the prefix length and interface identifier length
  does not equal 128 bits, the Prefix Information option MUST be
  ignored."

I think the statement in RFC2464 makes sense. I do not believe your 
implementation follows Section 4 of RFC2464. i.e. You form your IID 
differently.

Thanks
Suresh

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 20:46:29 +0100

JINMEI Tatuya / 神明達哉 a écrit :
> At Wed, 18 Feb 2009 17:56:43 +0100, Alexandru Petrescu
> <[email-masked]> wrote:
> 
>>> An IPv6 address prefix used for stateless autoconfiguration
>>> [ACONF] of an Ethernet interface must have a length of 64 bits.
>> I disagree with this.  There's an implementation of SLAAC over
>> Ethernet whose prefix can be shorter than 64 and works ok.  I
>> suppose there's at least another similar implementation.
> 
> implementation that doesn't follow the standard cannot be a reason
> for changing the standard.  If we really want to do that, there
> should be a clearer and stronger reason.
> 

I understand much discussion was about length of the IID.

But this is solely about the prefix, which could be shorter than 64.
Keep same IID length 64.

In this sense - what do you think about an RA containing a 56bit prefix
and used by a Ethernet receiver using 64bit IID?

> identifier), and for what does it use the larger IFID space?

No, I didn't mean larger than 64bit IID.  Same 64bit IID.

Alex

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 18 Feb 2009 14:53:46 -0500

Alex,

While I believe that Suresh is correct in the case of RFC 2464, I am very interested in the Ethernet implementation that supports non-64 bit IID. Do you have a reference for this implementation? Further, are you interested in supporting non-64 bit network prefixes? If so, let me know offline and we can discuss.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Wednesday, February 18, 2009 2:03 PM
To: Alexandru Petrescu
Cc: 6man
Subject: Re: Questions about rfc2464 IPv6 over Ethernet

Hi Alex,

* IID formation

Thanks
Suresh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 20:57:48 +0100

Suresh Krishnan a écrit :
> looks fine.

In this sense, I think that rfc2464 section should be titled "Parameters 
for SLAAC" instead of "Stateless Autoconfiguration" (sounds as if the 
IID is statelessly autoconfigured).

This rfc2464 section was used as inspiration at least for the 6LoWPAN 
IPv6 over 802.15.4 RFC.  Reading that RFC and finding a section titled 
"Stateless Address Autoconfiguration" was very surprising to me.  And it 
doesn't define "DAD params"  either.

> It is certainly not worth a bis :-)

Maybe an errata?

>> Ethernet whose prefix can be shorter than 64 and works ok.  I suppose 
>> there's at least another similar implementation.
> 

No no, the IID is still 64bit.  Just the prefix advertised in the RA is 
shorter than 64bit.  And the sum is indeed less than 128.

How about modifying the paragraph you cite above to say: "If the sum is 
larger than 128..."

Alex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 18 Feb 2009 12:03:08 -0800

At Wed, 18 Feb 2009 20:46:29 +0100,

> But this is solely about the prefix, which could be shorter than 64.

That's effectively the same thing - if you use a shorter prefix to
identify a on-link subnet, you effectively enlarge the IID.

> and used by a Ethernet receiver using 64bit IID?

I'd think it simply breaks the standard, but I actually don't
understand the point of the question in the first place.  Maybe you
want to explain what you're going to do with the additional 8bit
space, and then ask others what they think about it.

> No, I didn't mean larger than 64bit IID.  Same 64bit IID.

See above, it's effectively the same thing, and my question still
stands.  If you want to call it a shorter prefix with the same length
of IID, that's fine.  But my question would then be: what's the
implementation that uses a shorter prefix?  For what does it use the
remaining space between the prefix and the IID?

---
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 21:03:54 +0100

Dunn, Jeffrey H. a écrit :
> Alex,
> 
> While I believe that Suresh is correct in the case of RFC 2464, I am 
> very interested in the Ethernet implementation that supports non-64 
> bit IID. Do you have a reference for this implementation? Further, 
> are you interested in supporting non-64 bit network prefixes? If so, 
> let me know offline and we can discuss.

Hi Jeff, this (non-rfc2464 IIDs) is possible for other reasons, but
hasn't been implemented.  I'm happy interest is expressed.

In the previous mail I meant to say typical 64bit Ethernet IIDs but
shorter prefix (shorter than 64bit, for example 56bit).  This
implementation is what I meant I know exists.

Why is this useful?  BEcause it is easier to send RAs with a prefix
length that reflects the prefix length really assigned to that router.

Actually I'm very surprised to learn people seem to agree all Ethernet
links should have precisely 64bit prefixes in the RAs.

Alex

> 
> Best Regards,
> 
> Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 
> 448-6965 (mobile)
> 
> 
> -----Original Message----- From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Suresh Krishnan Sent: 
> Wednesday, February 18, 2009 2:03 PM To: Alexandru Petrescu Cc: 6man
>> I think a better title for this would be "Forming an IID for 
>> Ethernet". Because that's what the majority of the text of the 
>> section describes.
> 
> * IID formation * DAD params (mainly DupAddrDetectTransmits)
> 
> RFC2464 defines the former while leaving the latter undefined and 
> hence using the default(1). So, I think it is defining SLAAC 
> parameters. I do not have a strong preference, but the way I see it, 
> the current title looks fine. It is certainly not worth a bis :-)
> 
>> And because it sounds too much as "Stateless Address 
>> Autoconfiguration" described in rfc4862, which is much more than 
>> just forming an IID, and has message exchanges.
>> 
> Given that the EUI-64 identifier as described in RFC2464 is 64 bits 
> long and the following statement in RFC4862
> 
> "If the sum of the prefix length and interface identifier length does
>  not equal 128 bits, the Prefix Information option MUST be ignored."
> 
> Thanks Suresh
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 21:20:14 +0100

> identify a on-link subnet, you effectively enlarge the IID.

Well no, I don't need to enlarge the IID.  It is ok as it is.

> space, and then ask others what they think about it.

Well, nothing, do nothing with the additional 8bit space.  Make it 0, 
that's it.

> remaining space between the prefix and the IID?

It doesn't use it for anything.  It is there just in order to put a 
56bit prefix in the RA and the other end to auto-configure an address ok.

Why should I put a /64 in the RA when that link is adminsitratively 
assigned a /56.

Alex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 18 Feb 2009 12:30:31 -0800

At Wed, 18 Feb 2009 21:20:14 +0100,

> Well, nothing, do nothing with the additional 8bit space.  Make it 0, 

Then I don't think you can convince others (including myself) to
change the spec.

> Why should I put a /64 in the RA when that link is adminsitratively 

If your goal is to use a /56 as an on-link prefix while using
stateless autoconfiguration, you can do it without changing the
standard by advertising:

- prefix P::/56 with L=1, A=0, and
- prefix P::/64 with L=0, A=1

if the receiving host is fully compliant with RFC4861 and 4862.

---
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Feb 2009 07:06:01 +1030

On Wed, 18 Feb 2009 21:03:54 +0100

> length that reflects the prefix length really assigned to that router.

Isn't a /64 big enough for all conceivable and practical subnets ? Some
people want to make that longer because they consider it to be way too
much!

> links should have precisely 64bit prefixes in the RAs.

It's all links, not just Ethernet, because it's simpler to work with.
If every subnet is a constant /64, then you never need to specify it,
and nobody can ever make configuration errors.

Variable length node addresses in IPv4 make sense because IPv4's
address space is small and tight. With 128 bit IPv6 addresses, there
isn't that issue, so operational simplicity becomes more important.

Regards,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 21:54:37 +0100

> Then I don't think you can convince others (including myself) to

Well thank you for the advice anyways :-)

> if the receiving host is fully compliant with RFC4861 and 4862.

Excuse my ignorance but I don't see why putting two prefixes in the RA 
when one is sufficient with A=1 and L=1.

I'll check that in implementation, thanks.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 22:16:33 +0100

Mark Smith a écrit :
> On Wed, 18 Feb 2009 21:03:54 +0100 Alexandru Petrescu
>>> While I believe that Suresh is correct in the case of RFC 2464, I
>>> am very interested in the Ethernet implementation that supports
>>> non-64 bit IID. Do you have a reference for this implementation?
>>> Further, are you interested in supporting non-64 bit network
>>> prefixes? If so, let me know offline and we can discuss.
> Isn't a /64 big enough for all conceivable and practical subnets ?

Well yes.  I think /64 is big enough, maybe more than necessary.

But if I'm allocated a /48 and do a few subnetting I arrive to around
/56 or /60 to my edge networks.  Thus I don't understand why forcing
them to be /64.

> Some people want to make that longer because they consider it to be
> way too much!

Well yes, I have even crazier ideas - non-contiguous prefixes (reuse the 
wasted fffe space in the middle of the IID), but here I'm not 
complaining about that.  It'll never fly at IETF anyways.

>> Actually I'm very surprised to learn people seem to agree all
>> Ethernet links should have precisely 64bit prefixes in the RAs.
>> 
> 
>  If every subnet is a constant /64, then you never need to specify
> it, and nobody can ever make configuration errors.
 >

Well operational simplicity may be apparent, sometimes not :-)

A typical dialogue goes like this:
"how much IPv6 space do you need for your network?"
"what's IPv6?"
"ok, here you go a RA /64 is large enough for you, and Ethernet SLAAC
  can't do otherwise anyways"
"thanks!"
ten days later
"but how could I ever subnet that?"

Were it to say SLAAC Ethernet could be a /56 then people could further 
subnet between /56 and /64.

This is just one effect, and there are more like that.

Alex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 18 Feb 2009 13:38:59 -0800

At Wed, 18 Feb 2009 21:54:37 +0100,

> when one is sufficient with A=1 and L=1.

Because the specification is written that way.  From a pure technical
point of view, we could have introduced a new rule, e.g., "if the
length of a prefix with A=1 is less than 128 - length of IID, the host
should continue configuring an address with the prefix and the IID,
filling in the remaining bits with 0".  My whole point is that it's
not worth the time and process overhead to consider introducing such
an additional extension at this stage without a strong reason, and 'we
could do it, why not' is (IMO) way too weak a reason.

---
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Feb 2009 08:19:02 +1030

On Wed, 18 Feb 2009 22:16:33 +0100

> Well operational simplicity may be apparent, sometimes not :-)

It's no apparent to me - I've run IPX networks, so I *know* it's
simpler :-) Learning IPv4 and it's subnetting was hardwork after having
"learned" or just had work IPX networking. But that was the difference
between protocols designed in the late 1970s vs the mid to late 1980s.

> "how much IPv6 space do you need for your network?"

That question generally isn't really intended to be asked anymore. The
common case intent is that most people will always get enough address
space for what they need - actually far more than what they need, so
that they rarely if ever need to come back and ask for more. IPv6
address space is really "cheap", so it doesn't hurt to give people much
more than what they need, so they don't have to come back for more.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 10:59:14 +1300

> could do it, why not' is (IMO) way too weak a reason.

Yes, it seems to me that we have an unwritten consensus to keep RAs
rather simple. And we have RFC3633 and as of today,
draft-jaehwoon-autoconf-dhcpoption, to convey prefixes using DHCPv6.

   Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Feb 2009 17:22:06 -0500

> could do it, why not' is (IMO) way too weak a reason.

+1. In addition, nothing prevents a compliant router implementation from 
getting a P::/56 using DHCP-PD and zeroing out the next 0 bits in 
announcing a P::/64 on the pertinent link. This will achieve everything 
you want.

Cheers
Suresh

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 00:01:29 +0100

Suresh Krishnan a écrit :
>> Because the specification is written that way.  From a pure
>> technical point of view, we could have introduced a new rule, e.g.,
>> "if the length of a prefix with A=1 is less than 128 - length of
>> IID, the host should continue configuring an address with the
>> prefix and the IID, filling in the remaining bits with 0".  My
>> whole point is that it's not worth the time and process overhead to
>> consider introducing such an additional extension at this stage
>> without a strong reason, and 'we could do it, why not' is (IMO) way
>> too weak a reason.
> 
> +1. In addition, nothing prevents a compliant router implementation
> from getting a P::/56 using DHCP-PD and zeroing out the next 0 bits
> in announcing a P::/64 on the pertinent link. This will achieve
> everything you want.

Well yes, maybe two prefixes in an RA may be inefficient.

But now that we talk DHCPv6 PD.  What /64 will the requesting and
delegating router advertise on their own interfaces (knowing the method
is to delegate several /64s out of /60 which are themselves several out
of a /56):

(SERVER)--R1--R2--(ENDHOST)
         56  60  64

Were the /64 SLAAC Ethernet limit removed, the figure would make a lot
of sense, otherwise I'm forced to draw it as:

(SERVER)--R1--R2--(ENDHOST)
         56  60  64
         64  64  64

Which is prone to many misinterpretations.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 00:02:22 +0100

JINMEI Tatuya / 神明達哉 a écrit :
> At Wed, 18 Feb 2009 21:54:37 +0100, Alexandru Petrescu
>>> - prefix P::/56 with L=1, A=0, and - prefix P::/64 with L=0, A=1
>>> 
>> Excuse my ignorance but I don't see why putting two prefixes in the
>> RA when one is sufficient with A=1 and L=1.
> 
> length of a prefix with A=1 is less than 128 - length of IID, the
> host should continue configuring an address with the prefix and the
> IID, filling in the remaining bits with 0".

Technically that may sound absolutely wonderful, but I agree maybe more 
motivation is needed.

> My whole point is that it's not worth the time and process overhead
> to consider introducing such an additional extension at this stage

Well, I agree.  This is not because we could do it.

Were it said a RA prefix for Ethernet SLAAC could be shorter than /64, 
there could be some advantages for: administrative headaches, saving 
wireless bandwidth, easier DHCPv6 PD, avoid prefix-per-host address 
waste, motivate design of shared multicast-capable links (on which ND 
and others depend so largely), replace some proxy ND bridges with 
routers, and maybe more.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 00:08:18 +0100

Mark Smith a écrit :
> On Wed, 18 Feb 2009 22:16:33 +0100 Alexandru Petrescu 
>>>>> While I believe that Suresh is correct in the case of RFC 
>>>>> 2464, I am very interested in the Ethernet implementation 
>>>>> that supports non-64 bit IID. Do you have a reference for 
>>>>> this implementation? Further, are you interested in 
>>>>> supporting non-64 bit network prefixes? If so, let me know 
>>>>> offline and we can discuss.
>>>> Hi Jeff, this (non-rfc2464 IIDs) is possible for other reasons,
>>>>  but hasn't been implemented.  I'm happy interest is expressed.
>>>> 
>>>> 
>>>> In the previous mail I meant to say typical 64bit Ethernet IIDs
>>>>  but shorter prefix (shorter than 64bit, for example 56bit). 
>>>> This implementation is what I meant I know exists.
>>>> 
>>>> Why is this useful?  BEcause it is easier to send RAs with a 
>>>> prefix length that reflects the prefix length really assigned 
>>>> to that router.
>>>> 
>> But if I'm allocated a /48 and do a few subnetting I arrive to 
>> around /56 or /60 to my edge networks.  Thus I don't understand why
>>  forcing them to be /64.
>> 
>>> Some people want to make that longer because they consider it to 
>>> be way too much!
>> Well yes, I have even crazier ideas - non-contiguous prefixes 
>> (reuse the wasted fffe space in the middle of the IID), but here 
>> I'm not complaining about that.  It'll never fly at IETF anyways.
>> 
>>> It's all links, not just Ethernet, because it's simpler to work 
>>> with. If every subnet is a constant /64, then you never need to 
>>> specify it, and nobody can ever make configuration errors.
>>> 
>>> address space is small and tight. With 128 bit IPv6 addresses, 
>>> there isn't that issue, so operational simplicity becomes more 
>>> important.
> simpler :-) Learning IPv4 and it's subnetting was hardwork after 
> having "learned" or just had work IPX networking. But that was the 
> difference between protocols designed in the late 1970s vs the mid to
>  late 1980s.

Ah yes, that sounds right :-)

>> A typical dialogue goes like this: "how much IPv6 space do you need
>>  for your network?"
> 
> That question generally isn't really intended to be asked anymore.

Yet it pops up in so many settings I see regularly when building new
networks :-)  I don't think it will ever go away.

> The common case intent is that most people will always get enough 
> address space for what they need - actually far more than what they 
> need, so that they rarely if ever need to come back and ask for more.
>  IPv6 address space is really "cheap", so it doesn't hurt to give 
> people much more than what they need, so they don't have to come back
>  for more.

Well somewhere here there's a paradox.  An operator gives me a /64
telling me it's more than I'd ever need.  Which is true, it could
accommodate 2^64 nodes.

Yet I can't subnet it.  Only one subnet!  Which of course can't support
2^64 nodes because the link layer can't support that.

Were that /64 prefix of the Ethernet SLAAC be more flexible (the prefix,
not the IID), the operator would be more aware of this impossibility to
subnet.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 00:15:48 +0100

Following up my own post, detailing what I meant, and limiting my email
sending rate right after :-)

Saving wireless bandwidth: allow to send only one PIO in the RA instead
of two.  This may be useful for links with limited bandwidth which
imitate the Ethernet API. (e.g. 802.15.4, 802.16).

Avoid administrator headaches: allow putting only one Prefix/Length in
the config file, instead of two.

Avoid need for bridges and proxy ND: avoid the misunderstanding whereby
users try to build bridges (Proxy ND) instead of real routers.

Subnet power to the user: avoid IPv6 provider to take the /64 SLAAC
Ethernet limit as enough for many.  Provider could thus offer users a
/63 allowing her/him to further subnet.

DHCPv6 PD power: allow a Prefix Delegation scheme to re-delegate further
(a /56 out of a /52 out of a /48) without each router needing to reserve
a /64 for its own links.

Avoid prefix-per-host address waste: were it known a /56 could be used
to SLAAC an Ethernet interface - it would be very hard to claim there
are enough /56 prefixes to accomodate one for each mobile.  Or, that is
the situation today with /64 (RFC IPv6 cellular, RFC Proxy Mobile IPv6),
a situation which - if put in practice - effectively leads to address
waste.  Avoiding prefix-per-host could also lead to designing shared
multicast-capable link layers (for 802.16, 802.15.4), on which ND and
other IPv6 protocols depend so largely.

Alex

Alexandru Petrescu a écrit :
>>> Excuse my ignorance but I don't see why putting two prefixes in
>>> the RA when one is sufficient with A=1 and L=1.
>> 
>> prefix and the IID, filling in the remaining bits with 0".
> 
> Technically that may sound absolutely wonderful, but I agree maybe
> more motivation is needed.
> 
>>  without a strong reason, and 'we could do it, why not' is (IMO)
>> way too weak a reason.
> 
> Were it said a RA prefix for Ethernet SLAAC could be shorter than
> /64, there could be some advantages for: administrative headaches,
> saving wireless bandwidth, easier DHCPv6 PD, avoid prefix-per-host
> address waste, motivate design of shared multicast-capable links (on
> which ND and others depend so largely), replace some proxy ND bridges
> with routers, and maybe more.
> 
> Alex
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Feb 2009 18:28:17 -0500

Hi Alex,

> is to delegate several /64s out of /60 which are themselves several out

Maybe I am misunderstanding you, but this is an implementation detail 
and is not required to be standardized. The RR gets custody of the 
complete (shorter) prefix and is free to do whatever with it. Let's say 
my implementation fills it with 0's to get the longer prefix, 
Jinmei-san's with 1's and yours with a random bit string, we can all 
happily interoperate.

Cheers
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 13:18:07 +1300

On 2009-02-19 12:15, Alexandru Petrescu wrote:

...
> waste.  

Right, in an addressing scheme that allows 35 trillion /48s, it's easy
to see how we'll run out of /64s, not.

Sorry, but this line of argument just doesn't make sense to me. It isn't
even obvious to me that giving a /56 to every cell phone would be a problem.
Every /21 contains about 68 billion /56s.

(Yes, I know that we could blow things by foolish allocation policies,
but the RIRs don't have foolish policies, in general).

   Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Feb 2009 19:42:55 +1030

On Thu, 19 Feb 2009 00:08:18 +0100

> >>>> Dunn, Jeffrey H. a écrit :
<snip>
> telling me it's more than I'd ever need.  Which is true, it could

Well, if you have an alernative providers that will give you /48s (or
maybe /56s - I don't really like them, because now there's two
allocation sizes instead of the single /48 size, but they're still far
better than being given a single /64), give them your business instead.
The single /64 operator is being excessively and unnecessarily
conservative with IPv6 address space. You shouldn't have to work around
their unnecessary IPv6 address space constraints, and neither should
equipment vendors or the IETF.

Regards,
Mark.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 19 Feb 2009 10:55:36 -0800

At Thu, 19 Feb 2009 00:15:48 +0100,

> imitate the Ethernet API. (e.g. 802.15.4, 802.16).

Yes, this is certainly a waste.  The problem is how common this type
of configuration is, especially for such highly bandwidth sensitive
environments.  And the next question is whether it's serious enough to
warrant an update to the standard.  Personally, I'm not yet convinced
on that point.

> users try to build bridges (Proxy ND) instead of real routers.

My above question also applies here.  Plus, IMO I believe this can be
well handled in implementations.

> /63 allowing her/him to further subnet.

I don't understand the logic here, especially about how this leads to
loosen the restriction of 'len(prefix) + len(IID) must be 128'.

> (a /56 out of a /52 out of a /48) without each router needing to reserve

Again, I don't understand it.

If what you mean is something like this:
- router A advertises P::/48 with L=1, A=1
- router B (a downstream of A) advertises P::/52 with L=1, A=1
- router C (a downstream of B) advertises P::/56 with L=1, A=1
while allowing hosts to configure addresses with the shorter prefixes,
then hosts won't be able to communicate off-link: host X, which
receives an RA from router C and configures P::x, would tries neighbor
discovery to send packet to a different host Y, which receives an RA
from router A and configure P::y, because P::y is covered by X's
on-link prefix, P::/56.  This attempt will of course fail.

> other IPv6 protocols depend so largely.

I'm with Brian here.  With all due respect, this sounds like a
hairsplitting to justify the new rule of allowing address
configuration with a shorter length prefix.

If you have a real world problem that can only be solved by such a new
rule, please go ahead writing a draft with detailing the problem and
explaining why the new rule is inevitable.  I don't think continuing
the hypothetical argument here will lead us to anywhere constructive.

---
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 21:56:21 +0100

JINMEI Tatuya / 神明達哉 a écrit :
> At Thu, 19 Feb 2009 00:15:48 +0100, Alexandru Petrescu 
>> Following up my own post, detailing what I meant, and limiting my 
>> email sending rate right after :-)
>> 
>> Saving wireless bandwidth: allow to send only one PIO in the RA 
>> instead of two.  This may be useful for links with limited 
>> bandwidth which imitate the Ethernet API. (e.g. 802.15.4, 802.16).
> 
>  environments.  And the next question is whether it's serious enough 
> to warrant an update to the standard.  Personally, I'm not yet 
> convinced on that point.

I think this unique point does not warrant a modification.  The grouping
of all these points may.

>> Avoid administrator headaches: allow putting only one Prefix/Length
>>  in the config file, instead of two.
>> 
>> Avoid need for bridges and proxy ND: avoid the misunderstanding 
>> whereby users try to build bridges (Proxy ND) instead of real 
>> routers.
> 
>>  Ethernet limit as enough for many.  Provider could thus offer 
>> users a /63 allowing her/him to further subnet.
> 

Of course, to losen it on the lower side - it must be lower than or
equal to 128.

For ADSL.  If operator knows a /56 can be used to SLAAC an Ethernet
interface then operator can deliver a /56 to end user.  Operator is also
forced to implement DHCPv6 PD Server in the ADSL box.

In current state: operators can't really evaluate what a user needs.
Operator makes a safe bet; operator assumes that user needs the /64
becuase user certainly has Ethernet devices and, knowing Ethernet SLAAC
can only be /64, operator delivers a /64 to end user.  And is freed from
implementing DHCPv6 PD.

>> DHCPv6 PD power: allow a Prefix Delegation scheme to re-delegate 
>> further (a /56 out of a /52 out of a /48) without each router 
>> needing to reserve a /64 for its own links.
> 

Thanks for digesting an example.  I suppose the illustration is:

     48   52   56
--A----B----C---
      |         |
      Y         X

You seem to say that if RA /56 A=L=1 for X, and /48 for Y, and if X
wants to send a packet to Y (having never sent it a packet before) - it
will fail.  However, if X and Y were autoconfigured with /64 prefixes
then it would work; if Iunderstand you correctly.

>> Avoid prefix-per-host address waste: were it known a /56 could be 
>> used to SLAAC an Ethernet interface - it would be very hard to 
>> claim there are enough /56 prefixes to accomodate one for each 
>> mobile.  Or, that is the situation today with /64 (RFC IPv6 
>> cellular, RFC Proxy Mobile IPv6), a situation which - if put in 
>> practice - effectively leads to address waste.  Avoiding 
>> prefix-per-host could also lead to designing shared 
>> multicast-capable link layers (for 802.16, 802.15.4), on which ND 
>> and other IPv6 protocols depend so largely.
> 

I'm generally tempted to silently agree with Brian.  But on this
particular point I think I'll stick to the waste aspect - waste is not
good regardless of the space size.

> If you have a real world problem that can only be solved by such a
> new rule,

Certainly I'm not saying this out of the blue.

I've cited a number of IETF documents which I believe could have been 
written differently were that /64 SLAAC Ethernet limitation disappear.

> please go ahead writing a draft with detailing the problem and

Well thank you for the invitation.  I will leave it here, no draft for
the moment.  The implementation details and test you propose can only be
checked later, it takes ages to have this back up.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2009 22:05:17 +0100

Mark Smith a écrit :
> On Thu, 19 Feb 2009 00:08:18 +0100 Alexandru Petrescu
> allocation sizes instead of the single /48 size, but they're still
> far better than being given a single /64), give them your business
> instead. The single /64 operator is being excessively and
> unnecessarily conservative with IPv6 address space.

For clarification, the ADSL operator I'm mentioning is offering actually
less than /64 to the box (40-something or so IIRC).  But it only sends
/64 to the interface towards the user Ethernet cable.  And it does not
implement DHCPv6 PD.

The /64 aspect of SLAAC and Ethernet is so popular and widely known that
many think that's all that's needed.  Were that /64 SLAAC Ethernet limit
be more vague, like any figure between 48 and 64, then the belief of /64
is all that's needed for EThernet wouldn't have become so mainstream.

> You shouldn't have to work around their unnecessary IPv6 address
> space constraints, and neither should equipment vendors or the IETF.

Well far from me the intention to persuade neither IETF nor equipment 
vendors nor operators.

It's a remark about documents and their interpretations.

Alex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 19 Feb 2009 13:31:12 -0800

At Thu, 19 Feb 2009 21:56:21 +0100,

> then it would work; if Iunderstand you correctly.

Let's be even more specific.

Assume the /48 prefix is 2001:db8:1111::/48.

What I thought in the previous message was:

- A (or B) advertises 2001:db8:1111::/48 and Y configures
  2001:db8:1111::1 (by the hypothetical extension for address
  configuration).
- C advertises 2001:db8:1111::/56 and X configures 2001:db8:1111::2
  (by the hypothetical extension for address configuration).

but by being specific I realized I should have used a different
example.  So let me revise the situation:

Assume the /48 prefix is 2001:db8:1111::/48.
- A (or B) advertises 2001:db8:1111::/48 and Y configures
  2001:db8:1111::1 (by the hypothetical extension for address
  configuration).
- C advertises 2001:db8:1111:cc00::/56 and X configures
  2001:db8:1111:cc00::2 (by the hypothetical extension for address
  configuration).

The revised question is, how can host Y send a packet destined to
2001:db8:1111:cc00::2 via router B, instead of directly trying
neighbor discovery (which will fail)?  Since Y is told
2001:db8:1111::/48 (which covers 2001:db8:1111:cc00::2) as an on-link
prefix, the destination address should be a neighbor of Y.

---
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Feb 2009 10:04:58 +1100

In message <[email-masked]
se.org>, Mark Smith writes:
> > Mark Smith a =E9crit :
> > > On Wed, 18 Feb 2009 22:16:33 +0100 Alexandru Petrescu =
> 
> > > =
> > >> Mark Smith a =E9crit :
> > >>> On Wed, 18 Feb 2009 21:03:54 +0100 Alexandru Petrescu =
> 
> > >>> =
> > >>>> Dunn, Jeffrey H. a =E9crit :
> > >>>>> Alex,
> > >>>>> =
> 
> <snip>
> > =
> 
> > =
 
	Especially when the RIR's and LIR's are handing out address
	space to ISP's on the assumption they are in turn handing out
	/56 or /48's.
	
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2009 17:30:38 +0100

> prefix, the destination address should be a neighbor of Y.

That breaks (Y can't send to X) because by this hypothetical extension
the 2001:db8:1111::/48 is 'on-link' for the A-B link. Y uses
2001:db8:1111:cc00::2 to find a sort of longest-prefix match[*] in the
Neighbor Cache and finds 2001:db8:1111::/48. And then tries to NS/NA and
times out because no response. Ok.

You seem to say that if that on-link prefix were 2001:db8:1111::/64
(instead of 48) then Y-X communication would have worked; because
presumably the above sort of longest-prefix match wouldn't have hit
2001:db8:1111::/64, and no NS/NA but straight send to router. Ok.

But this means I couldn't accommodate the situation with two distinct
PIO prefixes in the RA either (/48 A=0 L=1, /64 A=1 L=0), because the
/48 L=1 prefix would still fool Y to believe 2001:db8:1111:cc00::2 were
on link.

Which is, again, a strange situation to be in.

Alex

[*]: 'sort of' longest prefix match because it's different than a
      typical longest-prefix match performed on the routing table
      (routing table and ND search algorithms differ on their inputs and
      stop conditions).

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 23 Feb 2009 08:45:47 -0800

At Mon, 23 Feb 2009 17:30:38 +0100,

> /48 L=1 prefix would still fool Y to believe 2001:db8:1111:cc00::2 were

In this case A (or B) normally only advertises 2001:db8:1111::/64 with
L=1 and A=1, and everything works just fine.  The example I gave was
to show that one of your suggested justification for the "hypothetical
extension" doesn't work in some cases.

---
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2009 17:50:03 +0100

> extension" doesn't work in some cases.

YEs, it wouldn't work, and for the same reason putting /48 with L=1 
would break the same example that the hypotethical extension breaks.

Alex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 23 Feb 2009 09:51:29 -0800

At Mon, 23 Feb 2009 17:50:03 +0100,

> would break the same example that the hypotethical extension breaks.

Of course not, but what are you trying to indicate by saying so?
Actually, I'm not sure if we're on the same page.  I've never
suggested the use of /48 with L=1 in this usage example.  The context
I mentioned this tricky setting is as follows:

At Wed, 18 Feb 2009 12:30:31 -0800,

> if the receiving host is fully compliant with RFC4861 and 4862.

you didn't explain any details about the network configuration at that
point, and my assumption (based on "link is administratively assigned
a /56") here was that no other subprefixes matching P::/56 are used
elsewhere.

On the other hand, what I've been questioning in the latest messages
was that the following cannot work as justification for the
hypothetical extension of SLAAC with /64 IID + a shorter prefix:

> (a /56 out of a /52 out of a /48) without each router needing to reserve

This is nothing to do with the P::/54 trick in the former scenario
(/48 is not assigned to "a link", but some "site", neither are /52,
/56.)

---
JINMEI, Tatuya