Subject: draft-yhb-6man-slaac-improvement-00

From: huabing yu <[email-masked]>
Date: Wed, 2 Mar 2011 09:21:33 +0800

Hi.
This is my draft, the link is

http://datatracker.ietf.org/doc/draft-yhb-6man-slaac-improvement/?include_text=1

Please give some advice.Thank you.

Abstract
IPv6 stateless address autoconfiguration described by RFC4862 only supports
64-bit prefixes. This approach can't be deployed in the sites with prefixes
longer than 64. We have no right to require that the sites MUST use 64-bit
prefixes. This document tries to implement stateless address
autoconfiguration with prefixes longer than 64.

Yu Hua bing

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Mar 2011 09:57:59 +1300

Hi

> We have no right to require that the sites MUST use 64-bit prefixes.

Actually, we do have that right. Since the IETF sets Internet standards,
we can write exactly what we want to. IETF standards are voluntary,
so sites have the right to ignore them too. However, if they do that,
they will not be able to interoperate with the Internet.

An accurate sentence for the draft would therefore be

[RFC4862] requires that subnets operating stateless address
autoconfiguration use 64 bit prefixes, and [RFC4291] requires
that interface identifiers conform to modified EUI-64 format.

However, the draft does not explain why this is a problem.
Since the Internet has only just run out of 24 bit prefixes,
why is there a risk of running out of 64 bit prefixes?

By the way, the proposed solution will not work with FireWire.

Regards
   Brian Carpenter

On 2011-03-02 14:21, huabing yu wrote:
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Mar 2011 16:25:47 -0500

> autoconfiguration use 64 bit prefixes,

Actually, not true! Stateless address autoconfiguration supports
different prefix lengths just fine. That was a deliberate design
decision, even after we switched to 64-bit Interface IDs. E.g (from
4862):

   A link-local address is formed by combining the well-known link-local
   prefix FE80::0 [RFC4291] (of appropriate length) with an interface
   identifier as follows:

   1.  The left-most 'prefix length' bits of the address are those of
       the link-local prefix.

   2.  The bits in the address to the right of the link-local prefix are
       set to all zeroes.

   3.  If the length of the interface identifier is N bits, the right-
       most N bits of the address are replaced by the interface
       identifier.

   If the sum of the link-local prefix length and N is larger than 128,
   autoconfiguration fails and manual configuration is required.  The
   length of the interface identifier is defined in a separate link-
   type-specific document, which should also be consistent with the
   address architecture [RFC4291] (see Section 2).  These documents will
   carefully define the length so that link-local addresses can be
   autoconfigured on the link.

and so on.

> and [RFC4291] requires that interface identifiers conform to
> modified EUI-64 format.

That is where the effective requirement is hard coded in. 

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Mar 2011 11:10:09 +1300

I stand corrected.

BTW there is also the issue of interaction with ILNP, which
has been recommended to the IETF by the RRG chairs.

   Brian

---

From: Scott W Brim <[email-masked]>
Date: Wed, 2 Mar 2011 17:23:57 -0500

On Wed, Mar 2, 2011 at 17:10, Brian E Carpenter <[email-masked]
> wrote:

> has been recommended to the IETF by the RRG chairs.

ILNP is barely experimental, its probability of being widely deployed is
totally unknown, and in any case sites that want to run ILNP MAY adhere to a
64-bit minimum themselves without making that even a SHOULD for everyone.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Mar 2011 11:32:42 +1300

> 64-bit minimum themselves without making that even a SHOULD for everyone.

That's all certainly true. However, the idea that we might have one set of
sites running ILNP and another set of sites running >64 bit prefixes seems
like Balkanization to me, even though it may not strictly speaking cause
interoperability failures. In any case my point is that it should be mentioned
in the draft, like the Firewire issue.

I'd rather get IPv6 deployed in a uniform way first.

   Brian

---

From: TJ <[email-masked]>
Date: Wed, 2 Mar 2011 17:58:37 -0500

On Wed, Mar 2, 2011 at 17:32, Brian E Carpenter <[email-masked]
> wrote:

<snip>

I'd take that sentence a step or two further:

"I'd rather get IPv6 deployed in a uniform way."

or even simpler:

"I'd rather get IPv6 deployed."

To be (perhaps overly) blunt: IMHO the changes proposed in this draft create
unneeded confusion, solve a problem that is either non-existent or is
readily solved in other ways and can create functional problems / detriments
to actual deployment.

Note: I am ready, willing and (often!) able to be proven wrong ... (and
welcome the conversation!)

/TJ

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Mar 2011 09:36:39 +0900

> I'd rather get IPv6 deployed in a uniform way first.

try cidr

---

From: Bob Hinden <[email-masked]>
Date: Thu, 3 Mar 2011 12:03:10 +0200

On Mar 3, 2011, at 12:58 AM, TJ wrote:

> On Wed, Mar 2, 2011 at 17:32, Brian E Carpenter <[email-masked]> wrote:
> 
> <snip>
> 
> To be (perhaps overly) blunt: IMHO the changes proposed in this draft create unneeded confusion, solve a problem that is either non-existent or is readily solved in other ways and can create functional problems / detriments to actual deployment.  

+1

Bob

---

From: "Yu Hua bing" <[email-masked]>
Date: Thu, 3 Mar 2011 22:50:26 +0800

I think that SLAAC should be deployed in the sites which use the prefixes longer than 64. 
Don't put a limit on the prefix length.
DHCPv6 can be deployed in the sites which use the prefixes longer than 64.Why can't SLAAC?
It is not reasonable.

From: TJ 
Sent: Thursday, March 03, 2011 6:58 AM
To: Brian E Carpenter 
Cc: Scott W Brim ; Thomas Narten ; ipv6 ; huabing yu 
Subject: Re: draft-yhb-6man-slaac-improvement-00

<snip>

Note: I am ready, willing and (often!) able to be proven wrong ... (and welcome the conversation!) 

/TJ

---

From: "Duncan, Richard J. (Jeremy) CONTRACTOR" <[email-masked]>
Date: Thu, 3 Mar 2011 09:56:22 -0500

I think that SLAAC should be deployed in the sites which use the prefixes
longer than 64. 

DHCPv6 can be deployed in the sites which use the prefixes longer than
64.Why can't SLAAC?

It is not reasonable.

No. EUI-64 requires 64 bit host id's.  48 bits is from the MAC.  How would
you plan to squeeze blood out of the proverbial turnip?

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

Defense Threat Reduction Agency (DTRA)
BE-BI INFOCON 3, IPv6 Architect
Command Information
Google Voice:  (540) 440-1193

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yu
Hua bing
Sent: Thursday, March 03, 2011 9:50 AM
To: [email-masked]; Brian E Carpenter
Cc: Thomas Narten; ipv6; Scott W Brim
Subject: [BULK] Re: draft-yhb-6man-slaac-improvement-00
Importance: Low

I think that SLAAC should be deployed in the sites which use the prefixes
longer than 64. 

DHCPv6 can be deployed in the sites which use the prefixes longer than
64.Why can't SLAAC?

It is not reasonable.

From: TJ <mailto:[email-masked]>  

To: Brian <mailto:[email-masked]>  E Carpenter 

Cc: Scott W Brim <mailto:[email-masked]>  ; Thomas Narten
<mailto:[email-masked]>  ; ipv6 <mailto:[email-masked]>  ; huabing yu
<mailto:[email-masked]>  

On Wed, Mar 2, 2011 at 17:32, Brian E Carpenter
<[email-masked]> wrote:

<snip>

or even simpler: 

 

 

/TJ

---

From: "Yu Hua bing" <[email-masked]>
Date: Thu, 3 Mar 2011 23:02:22 +0800

If the prefix is longer than 64, don't use EUI-64 interface ID.

   (7.2)If the prefix length is greater than 64 and is not greater than
   80, an address is formed by combining the advertised prefix with 
   the MAC address of the interface as follows:

      |            N bits            | (80 - N) bits |     48 bits     |
      +------------------------------+---------------+-----------------+
      |            link prefix       |   reserved    |   MAC address   |
      +----------------------------------------------------------------+
   (7.3) If the prefix length is greater than 80, a random number 
   between 0 and 2 ^ (128 - prefix length) is generated, and an address
   is formed by combining the advertised prefix with the random number
   as follows:
            
      |                N bits                 |       128 - N bits     |
      +---------------------------------------+------------------------+
      |            link prefix                |     random number      |
      +----------------------------------------------------------------+                    

From: Duncan, Richard J. (Jeremy) CONTRACTOR 
Sent: Thursday, March 03, 2011 10:56 PM
To: Yu Hua bing ; [email-masked] ; Brian E Carpenter 
Cc: Thomas Narten ; ipv6 ; Scott W Brim 
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00

It is not reasonable.

No. EUI-64 requires 64 bit host id's.  48 bits is from the MAC.  How would you plan to squeeze blood out of the proverbial turnip?

Jeremy Duncan

--------------------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Mar 2011 07:30:58 +1030

Hi,

I think your fundamental premise is flawed. You're saying that as an
upstream provider is precious about address space, and only going to
give out a /64, that it should be possible to subnet that /64 further. 
Unfortunately all I think that will do is also facilitate the upstream
provider pushing the initial allocation boundary even further to the
right. A really "precious" upstream provider will start handing
out /127s, /126s etc. because they now can - only as many as they
perceive you to "need" right now. You'll have to justify the
exact amount of address space you want, you'll have to deal with
them again to get more, and they'll have to manage their IPv6 address
space at an address rather than subnet level. All these costs are
necessary ones in IPv4, but don't need to exist in IPv6. There are no
useful benefits to be gained from paying them.

One thing I'm noticing is that when people find out that a /64 is the
basic minimum size for a subnet, and that it's all about numbers of
subnets, rather than numbers of addresses, they start to slowly stop
applying their IPv4 conserve addresses addresses mentality to IPv6. I
think moving away from a single and fixed size interface id will start
to encourage people to become more conservative again, unnecessarily.

Oh, and "waste" only occurs if you get no value when you use something -

" In fact,
   any LAN can't run out of so many IPv6 addresses, and only a very
   small part of IPv6 addresses are used, so it is a serious waste."

The value you get out of IPv6's (and also in fact Ethernet's) large
address space is convenience. If you have a car with an automatic
transmission, or electric windows, or central locking, or even an
electric start (i.e. you're not hand winding it to start it), you've
already placed value on having convenience. If the costs are low enough
(e.g. cheap addressing bits), data networking protocols should be
convenient to use too.

Regards,
Mark.

On Thu, 3 Mar 2011 23:02:22 +0800

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Mar 2011 10:41:26 +1300

Yes, and in fact draft-ietf-v6ops-3177bis-end-sites deals
with this and will be an RFC soon:

https://datatracker.ietf.org/doc/search/?name=draft-ietf-v6ops-3177bis-end-sites&rfcs=on&activeDrafts=on

Regards
   Brian Carpenter

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 3 Mar 2011 15:59:25 -0600

I guess I'm missing what the solution is.

As 3177-bis says, the IETF has no control over how service providers hand out IPv6 address space. From what I've been reading in the past few years, it looks like at least some providers are planning to give /64s to customers.

The way I see it, unless we permit SLAAC to use more than 64-bit prefixes, either of two things will happen.

1. SLAAC will not work inside home networks, except for the simplest one-computer case, or

2. Someone will have the brilliant idea to invent an IPv6 NAT.

As Mark points out, this may encourage providers to hand out /127s. So, rock and hard place. What's the answer, if no one can force providers to hand out AT LEAST /56s? NAT?

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Thursday, March 03, 2011 4:41 PM
> To: Mark Smith
> Cc: Thomas Narten; ipv6; Scott W Brim; Duncan,Richard J. (Jeremy)
> CONTRACTOR; Yu Hua bing
> Subject: Re: [BULK] Re: draft-yhb-6man-slaac-improvement-00
> 
> >>       |                N bits                 |       128 - N bits
> |
> >> No. EUI-64 requires 64 bit host id's.  48 bits is from the MAC.  How
> would you plan to squeeze blood out of the proverbial turnip?
> >>
> >>
> >>
> >>
> >>
> >>
> ------------

---

From: Tina Tsou <[email-masked]>
Date: Thu, 03 Mar 2011 14:02:06 -0800

Hi Bert,
Comments in line.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Manfredi, Albert E
Sent: Thursday, March 03, 2011 1:59 PM
To: Brian E Carpenter
Cc: ipv6
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00

As 3177-bis says, the IETF has no control over how service providers hand
out IPv6 address space. From what I've been reading in the past few years,
it looks like at least some providers are planning to give /64s to
customers.

The way I see it, unless we permit SLAAC to use more than 64-bit prefixes,
either of two things will happen.

1. SLAAC will not work inside home networks, except for the simplest
one-computer case, or

2. Someone will have the brilliant idea to invent an IPv6 NAT.
[Tina: do you mean NAT66?]

As Mark points out, this may encourage providers to hand out /127s. So, rock
and hard place. What's the answer, if no one can force providers to hand out
AT LEAST /56s? NAT?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Mar 2011 11:08:09 +1300

> As 3177-bis says, the IETF has no control over how service providers hand out IPv6 address space. From what I've been reading in the past few years, it looks like at least some providers are planni…

Then their customers will discover that they need to switch to
another ISP, won't they?

   Brian

---

From: TJ <[email-masked]>
Date: Thu, 3 Mar 2011 17:10:27 -0500

> I guess I'm missing what the solution is.
The solution is for providers to not give out just /64s :).

> it looks like at least some providers are planning to give /64s to

Really?  None of the ISPs I have spoken with, and certainly none of the ones
I have worked with, are following a /64 per client plan.  I have discussed
/48s vs /56s vs /60s ... but never a /64.  If you know of any /64ers, please
name-and-shame them - or atleast push them to start thinking more clearly!

/TJ

---

From: james woodyatt <[email-masked]>
Date: Thu, 03 Mar 2011 15:30:39 -0800

On Mar 3, 2011, at 2:10 PM, TJ wrote:
> Really?  None of the ISPs I have spoken with, and certainly none of the ones I have worked with, are following a /64 per client plan.  I have discussed /48s vs /56s vs /60s ... but never a /64.  If you know of any /64ers, please name-and-shame them - or atleast push them to start thinking more clearly!

Here is a Reddit commenter from Canada who claims to have been delegated a native /64 prefix by some unnamed service provider:

  <http://www.reddit.com/r/ipv6/comments/fvvh9/i_am_a_verizon_fios_customerwhen_can_i_get_on_ipv6/c1j10sy>

Not sure how credible that claim can be regarded, but it's a claim that can be checked.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Doug Barton <[email-masked]>
Date: Thu, 03 Mar 2011 16:14:23 -0800

> DHCPv6 can be deployed in the sites which use the prefixes longer than

Because SLAAC was not designed as a general-purpose mechanism, and 
should not be modified (further) to be so.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 3 Mar 2011 18:37:59 -0600

>> Really?  None of the ISPs I have spoken with, and certainly none of
>> the ones I have worked with, are following a /64 per client plan.  I
>> have discussed /48s vs /56s vs /60s ... but never a /64.

James Woodyatt wrote:

> Here is a Reddit commenter from Canada who claims to have been
> delegated a native /64 prefix by some unnamed service provider:
> 

I've certainly seen ISPs suggesting that they would do this. But a quick search turned up this, dated 2/8/2011:

http://www.ripe.net/ripe/docs/ripe-512#end_site

   5.4.1. Assignment address space size

   End Users are assigned an End Site assignment from their LIR or
   ISP. The size of the assignment is a local decision for the LIR
   or ISP to make, using a minimum value of a /64 (only one subnet
   is anticipated for the End Site).

So, is anyone willing to bet that ISPs won't use /64s?

Bert

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 11:42:07 +1100

In message <[email-masked]
.com>, "Manfredi, Albert E" writes:
> As 3177-bis says, the IETF has no control over how service providers hand out
> IPv6 address space. From what I've been reading in the past few years, it lo
> oks like at least some providers are planning to give /64s to customers.

Every ISP I've seen make that claim has also thought they need to
fit into a /32.  Once they were informed that that was not the case
they changed their plans.  Additionally the *nog lists see /56 as
being standard these days (changed from about 6 months ago).  There
are still arguments about /48 but the /56 vs /64 has gone to /56.

> and hard place. What's the answer, if no one can force providers to hand out 

Competition will.  CPE device manufactures will.  Prefix delegation
is being delivered today as part of the basic IPv6 functionality
set in CPE devices.

Remember HE hands out /48's for free to anyone in the world today.
6to4 delivers /48.  Current 6rd (RFC 5969) supports just about an
sized prefix.

I don't think this is something that needs to be solved as it is a
non problem.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 12:31:49 +1100

In message <[email-masked]
> So, is anyone willing to bet that ISPs won't use /64s?

And it use /56 for the HD-Ratio.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organisation (i.e.
ISP/LIR) satisfies the evaluation threshold of past address utilisation
in terms of the number of sites in units of /56 assignments. The
HD-Ratio [RFC 3194] is used to determine the utilisation thresholds
that justify the allocation of additional address as described
below.

The customer just needs to say "you are allocated space assuming
that you will be handing out up to /56's, please give me a /56".

Mark

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Mar 2011 18:10:12 +0900

> would you plan to squeeze blood out of the proverbial turnip?

perhaps going back and reading thomas's message would help dispel this
odd religion.

http://www.ietf.org/mail-archive/web/ipv6/current/msg13461.html

randy

---

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Mar 2011 18:30:40 -0700

> I stand corrected.

That said, updating the specs to allow a site to use stateless address
autoconfiguration with prefix lengths other than /64 would almost
certainly require updating both specs.

The stateless autoconfig spec would need to be tweaked to convert the
IID produced by the specific link-layer into something that is either
extended (or shrunk) to match the advertised prefix in an RA. And we'd
then have to recover from address collision (duplicate addresses),
which the current spec does not, and generate (and try) new addresses,
sort of like the temporary addresses spec defines.

This could probably all be defined in a way that is an optional
extension to stateless address autoconfig. So it wouldn't necessarily
cause "confusion" or delay getting IPv6 deployed. 

However, I wonder what incentive device implementors would have to
actually implement it. They seem (these days) to only implement the
bare minimal functionality needed to get by. Extensions that might be
useful in only some deployments, don't seem to be high priority.

And, if you have a network in which 80% of the devices implement the
new spec, but 20% do not, how useable would such a feature be in
practice?

And, keep in mind, one can use abitrary prefixes by turning off
stateless address autoconfiguration  and using DHCPv6.

Thomas

---

From: "Yu Hua bing" <[email-masked]>
Date: Sat, 5 Mar 2011 10:06:09 +0800

> cause "confusion" or delay getting IPv6 deployed. 

I agree.

Yu Hua bing

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Mar 2011 13:20:40 +0900

> stateless address autoconfiguration  and using DHCPv6.

we wish.  there is still the exciting mess of ra.

randy

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 18:10:39 +1030

On Sun, 06 Mar 2011 13:20:40 +0900

> we wish.  there is still the exciting mess of ra.

Your wishes are already true. You switch off the autonomous
address-configuration flag (A bit) for the prefix -

      A              1-bit autonomous address-configuration flag.  When
                     set indicates that this prefix can be used for
                     stateless address configuration as specified in
                     [ADDRCONF].

So in summary -

RA with M and O bits set
PIO in RA with prefix(es) with L bit on and A bit off

will force DHCPv6.

---

From: [email-masked]
Date: Sun, 06 Mar 2011 09:02:18 +0100 (CET)

> PIO in RA with prefix(es) with L bit on and A bit off

Or, alternatively, RA with M and O bits set and no prefix at all.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 19:03:09 +1030

> Or, alternatively, RA with M and O bits set and no prefix at all.

I don't think that will always work. The PIO is needed to indicate to
end-nodes what the onlink prefix(es) are, as per RFC5942.

---

From: [email-masked]
Date: Sun, 06 Mar 2011 09:49:11 +0100 (CET)

> end-nodes what the onlink prefix(es) are, as per RFC5942. 

Agreed, it won't always work. But it *can* work, if your deployment
model is DHCPv6 with IA_PD using the link-local address of the router
as next-hop.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 6 Mar 2011 09:54:42 +0100 (CET)

> end-nodes what the onlink prefix(es) are, as per RFC5942.

Why do they need to know that?

In our testing at least under Linux did just fine by knowing how to reach 
the router and that it needed to use (and actually used) DHCPv6 to get its 
IPv6 address. No on-link prefix was needed (or even desireable in some 
deployment scenarios).

Does RFC5942 says this is mandatory? I interpret 4.1 as this is definitely 
not mandatory, rather the opposite?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 19:35:23 +1030

> model is DHCPv6 with IA_PD using the link-local address of the router

i.e. an unnumbered link where there is no assigned prefix, and every
destination, other than link local ones, are considered to be off-link.
If you want a prefix to be considered on link, such as a group of
end-nodes LAN scenario, you need to announce it in a PIO (with A off if
you don't want SLAAC).

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 19:53:58 +1030

On Sun, 6 Mar 2011 09:54:42 +0100 (CET)

> IPv6 address. No on-link prefix was needed (or even desireable in some 

The PIO isn't to make DHCPv6 work, it is to inform the end-host of what
destinations are onlink. Here is what RFC5942 says -

   The behavior of IPv6 as specified in Neighbor Discovery (ND)
   [RFC4861] is quite different.  The on-link determination is separate
   from the address assignment.  A host can have IPv6 addresses without

Singh, et al.                Standards Track                    [Page 2]
^L
RFC 5942                    IPv6 Subnet Model                  July 2010

   any related on-link prefixes or can have on-link prefixes that are
   not related to any IPv6 addresses that are assigned to the host.  Any
   assigned address on an interface should initially be considered as
   having no internal structure as shown in [RFC4291].

   In IPv6, by default, a host treats only the link-local prefix as
   on-link.

   The reception of a Prefix Information Option (PIO) with the L-bit set
   [RFC4861] and a non-zero valid lifetime creates (or updates) an entry
   in the Prefix List.  All prefixes on a host's Prefix List (i.e.,
   those prefixes that have not yet timed out) are considered to be
   on-link by that host.

> Does RFC5942 says this is mandatory?

It updates 4861.

> I interpret 4.1 as this is definitely 

I'm not quite sure which 4.1 you're referring to. Point 1. of section 4
of RFC5942?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 6 Mar 2011 10:47:06 +0100 (CET)

> destinations are onlink. Here is what RFC5942 says -

Why does it need destinations on-link? It only needs to know it's IPv6 
address and how to reach the router, nothing more. I don't see any 
theoretical or practical MUST requirement for an on-link prefix.

> I'm not quite sure which 4.1 you're referring to. Point 1. of section 4 

Yes.

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 20:39:26 +1030

On Sun, 6 Mar 2011 10:47:06 +0100 (CET)

> theoretical or practical MUST requirement for an on-link prefix.

I don't think I said an on-link prefix was required. All I have ever
said is that, as per the RFC5942, if you want to have an on-link
prefix, you must announce it in a PIO (without the A bit if you don't
want it to be used for SLAAC). Steinar gave an example which could
imply that wasn't the case, but his example was actually one where an
on-link prefix wasn't required. IOW, his example didn't disprove my
statement, it only showed that there are some situations where no PIO
announced prefix has a use case - where all destinations are required
to be considered off-link.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 6 Mar 2011 11:40:12 +0100 (CET)

On Sun, 6 Mar 2011, Mark Smith wrote:

> want it to be used for SLAAC).

> end-nodes what the onlink prefix(es) are, as per RFC5942.

I interpreted your use of "needed" as "required".

> Steinar gave an example which could imply that wasn't the case, but his 
> example was actually one where an on-link prefix wasn't required. IOW, 
> his example didn't disprove my statement, it only showed that there are 
> some situations where no PIO announced prefix has a use case - where all 
> destinations are required to be considered off-link.

Well, I interpreted your "I don't think that will always work" as saying 
that you thought what he said wouldn't work in all sitations. What 
situations were you thinking of that won't work?

As far as I can see, not having an on-link prefix means all traffic will 
be passing via the router, but that's not the same as "not working", it 
might just be suboptimal in some deployment scenarios and highly desired 
in others.

---

From: [email-masked]
Date: Sun, 06 Mar 2011 14:34:31 +0100 (CET)

> to be considered off-link. 

I have a similar use case where some information seems to be missing
in the RFCs. Or maybe I haven't read them in sufficient detail.

Assume I want to assign addresses to clients using DHCPv6, using only
a link-local next-hop. So my router is sending RA with M and O bits
set and no PIO. However, my client requests IA_NA, not IA_PD. The
question is:

*What netmask should the client use for the received address* in this
case?

The only obvious alternatives I can think of are /64 and /128, since
the IA_NA address doesn't include a prefix length. Can anybody point
me to RFCs which describe this?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 6 Mar 2011 14:37:56 +0100 (CET)

> *What netmask should the client use for the received address* in this

When we tested this, it used /128 which is the only sane behaviour I can 
see.

> me to RFCs which describe this?

I think the RFC I quoted already says this, if you don't get an on-link 
prefix, you're not allowed to make up an on-link prefix. If you get an 
address, you get that single address, nothing else.

Thus the behaviour I've seen is correct, you end up with a /128 pointing 
to yourself and a default route pointing to the router LL address, nothing 
else.

---

From: Mark Smith <[email-masked]>
Date: Mon, 7 Mar 2011 07:44:35 +1030

On Sun, 6 Mar 2011 11:40:12 +0100 (CET)

> I interpreted your use of "needed" as "required".

As always context matters.

I was stating it in the common and usually unstated conext of the most
common case. Usually people want optimal traffic forwarding paths,
which on a multi-access, peer-to-peer layer 2 segment (e.g. an
Ethernet), means traffic is sent directly between attached nodes,
rather than "hair-pinned" or "trumbonned" through a default router. In
this common case, you'll need a PIO option with the L bit switched on,
to indicate the on-link prefix(es), regardless of the addressing
information and address prefix length that DHCPv6 supplies.

In the less common cases of "non-link-local prefix-free" unnumbered
links, you don't need a PIO. In the less common case of DHCPv6 only
(M+O in RA) with hair-pinned traffic paths via a router on a
multi-access, peer-to-peer layer 2 segent, you don't need a PIO. In the
less common case of SLAAC only (-M -O in RA), with hair-pinned traffic
paths via a router on a multi-access, peer-to-peer layer 2 segment,
you'll need a PIO, with the A bit on, and the L bit switched off.