Subject: Off-link and on-link

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 5 Dec 2007 14:00:45 -0500

Hi Hesham/Dave/Erik,
  I am not taking a stand on whether an explicit off-link flag is necessary/useful or not, but I have encountered a scenario where the existing algorithm specified in RFC4861 does not work very well. Let's say a router wants to signal to the clients that 2001:dead:beef::/48 is on-link except for 2001:dead:beef:abcd::/64 that is off-link. How would it go about describing this? I see two ways

a) Advertise the /48 with L=0 and send redirects for all addresses not on the /64
b) Advertise the /48 with L=1 and the /64 with Q(the new off-link flag)=0

I see b) as being more efficient than a)

P.S: I do not think that this scenario is very likely, just possible.

Cheers
Suresh

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 14:09:25 -0500

Suresh,

At least our drafts do not ask for a new off-link flag. Without a new
off-link flag your scenario will have to go with (a). But do note,
aggregation routers do not send Redirects. So the scenario below cannot
be even supported on aggregation routers.

Hemant 

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 11:01 AM
To: [email-masked]
Subject: Off-link and on-link

Hi Hesham/Dave/Erik,
  I am not taking a stand on whether an explicit off-link flag is
necessary/useful or not, but I have encountered a scenario where the
existing algorithm specified in RFC4861 does not work very well. Let's
say a router wants to signal to the clients that 2001:dead:beef::/48 is
on-link except for 2001:dead:beef:abcd::/64 that is off-link. How would
it go about describing this? I see two ways

a) Advertise the /48 with L=0 and send redirects for all addresses not
on the /64
b) Advertise the /48 with L=1 and the /64 with Q(the new off-link
flag)=0

Cheers
Suresh

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 12:27:58 -0800

> a) Advertise the /48 with L=0 and send redirects for all addresses not on the /64

Alternatively you could advertize a set of /47 through /64 prefixes as 
on-link. I think in this case you'd end up with 15 or so prefixes being 
advertized.

> I see b) as being more efficient than a)

I think b) is a lot more complex to understand, because one would have 
to understand who wins when one RA says L=1 and onther says Q=1 and 
their is partial of complete overlap between the prefixes in question.
Also, depending on that preference issues, a sane host implementation 
might need to either have a positive (on-link) or negative (off-link) 
list of prefixes, which means the host would have to do the expansion.

One can illustrate this complexity by modifying your example to have 3 
sub-prefixes where
2001:dead:beef::/48 is on-link, except for
2001:dead:beef:ab00::/56 which is off-link, except for
2001:dead:beef:abcd::/64 which is on-link

> P.S: I do not think that this scenario is very likely, just possible.

I agree. And my example might be event more unlikely, but possible.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 12:28:37 -0800

> be even supported on aggregation routers.

Which RFC defines an "aggregation router"?

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 15:54:20 -0500

Good question, Erik. To the best of my knowledge such an RFC does not
exist - at least describing total details of an aggregation router -
like unicast, mcast, and anycast data forwarding rules etc.  The closest
I have found in IETF is what IETF calls as multi-link router.

A cable aggregation router is described in a cable docsis standard. Look
at the last standard by searching for this file.
CM-SP-SECv3.0-I05-070803.pdf. It will take a person new to cable a long
time to understand such a router behavior. I was here to explain that
behavior in the slides.

Anyhow, it's not rocket science to figure out basic behavior of a
aggregation router. I presented my slides that said an aggregation
router has subscriber hosts as always off-link to each other due to
physical connectivity of deployment. Well, if hosts are always off-link,
then the aggregation router is lying if the router sends any Redirects
to signal any prefix as on-link to a host. That is why such a deployment
for both IPv4 or IPv6 does not send Redirect. 

Now the question I asked in my presentation. I have to configure this
aggregation router to signal off-link. How do I do that?

Thanks.

Hemant

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 12:29 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]
Subject: Re: Off-link and on-link

Hemant Singh (shemant) wrote:
> aggregation routers do not send Redirects. So the scenario below 
> cannot be even supported on aggregation routers.

    Erik

> say a router wants to signal to the clients that 2001:dead:beef::/48 
> is on-link except for 2001:dead:beef:abcd::/64 that is off-link. How 
> would it go about describing this? I see two ways
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 16:05:17 -0500

Erik,

As I said in the presentation, let's forget the aggregation router. The
host implementation bug we found is reproduced in an Ethernet LAN
network too. An RA from the router was sent where RA was NOT signaling
on-link and the host still behaved as on-link for traffic forwarding.
The RA we used was an RA that did not send any PIO (Prefix Information
Option). BTW, such a case (RA with no PIO) is not even covered by the
definition of on- and off-link in section 2.1 of RFC 4861, especially
since section 2.1 goes to so much copious details to describe on-link.

I was looking for a Turing machine to signal off-link. 

Hemant 

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 12:29 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]
Subject: Re: Off-link and on-link

    Erik

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 6 Dec 2007 08:22:46 +1000

You've answered the question :) So what's the problem? As you said, this is
very unlikely but there is a solution for it below. 

Hesham 

 > Sent: Thursday, December 06, 2007 5:01 AM
 > To: [email-masked]
 >   I am not taking a stand on whether an explicit off-link 
 > flag is necessary/useful or not, but I have encountered a 
 > scenario where the existing algorithm specified in RFC4861 
 > does not work very well. Let's say a router wants to signal 
 > to the clients that 2001:dead:beef::/48 is on-link except 
 > for 2001:dead:beef:abcd::/64 that is off-link. How would it 
 > go about describing this? I see two ways
 >

---

From: Ralph Droms <[email-masked]>
Date: Wed, 5 Dec 2007 16:27:04 -0500

To give a little more detail to that implementation bug, it seems the  
host implementation inferred an on-link prefix from an address  
assigned through DHCPv6.  We believe the implementation carried over  
IPv4 behavior, in which it's common to pass on-link prefix information  
to a host as a side effect of address assignment to interfaces.  In  
IPv6, of course, RAs provide an explicit path for announcing prefix  
information, so no prefix state should be inferred from address  
assignment.

In my opinion, the "no PIO" case is adequately described in RFC 4861,  
as the host has no information about on-link status of a prefix if  
there is no PIO for that prefix.  Therefore, the host should send any  
outbound traffic to an address from a prefix for which the host has  
not received a PIO to the default router.

- Ralph

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 6 Dec 2007 08:32:16 +1000

> information, so no prefix state should be inferred from address  

=> Exactly. This makes sense, and it's good to highlight that to
implementations, I just don't think this behaviour is a result of correct
reading of the spec.

 > not received a PIO to the default router.

=> Agreed. That's the default behaviour.

Hesham

 > > As I said in the presentation, let's forget the 
 > aggregation router.  
 > > The
 > >> a) Advertise the /48 with L=0 and send redirects for all 
 > addresses  
 > >> not
 > >
 > >> on the /64
 > >> Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 > >> 
 > >> Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 > >> 
 > > Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 > >

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 13:45:56 -0800

> I have found in IETF is what IETF calls as multi-link router.

FWIW I don't find "multi-link router" in any RFC. My point was that 
using this undefined term doesn't help clarify things. It would have 
been better to talk about a router which has been configured to never 
send any redirects.

> aggregation router to signal off-link. How do I do that?

By not to configuring it to enable the L flag for any prefix that the 
router advertized. Abstractly (per RFC 4861) this is done by setting 
AdvOnLinkFlag=False.

If you have a question on how to do that for a particular product you 
should ask the vendor of that product. If you are using OpenSolaris I 
can help.

> on-link and the host still behaved as on-link for traffic forwarding.

That is clearly a bug in the host implementation.
Have you contacted the host vendor?

> since section 2.1 goes to so much copious details to describe on-link.

It does cover it. If no information is know about an address (which is 
this case - no prefix options with L=1 and no redirects) then the host 
will send to a default router.

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 17:10:58 -0500

Erik and Hesham, did you read our on-and-off-link draft? It has lot of
clarification data in the draft. Wrt to the problem Ralph mentioned
below, our draft says the following:

2.  The on-link definition in section 2.1 of RFC 4861 [ND] describes
       the only means for on-link determination.  DHCPv6 or any other
       configuration on the host MUST NOT be used for on-link
       determination.  Manual configuration of a host introduces its own
       set of security considerations and is beyond the scope of this

Singh & Beebee             Expires May 3, 2008                  [Page 3]

Internet-Draft          ND On-link Determination            October 2007

       document.  Note that the on-link definition as specified by RFC
       4861 [ND] does not include manual configuration.

This is a totally correct paragraph based off of RFC 4861, 4862, and
3315 (DHCPv6). 

It's a lot of things we are saying in our drafts that needed
clarification in 4861. It's not just one thing. 

Hemant 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, December 05, 2007 1:27 PM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; IPV6 List Mailing; Suresh Krishnan
Subject: Re: Off-link and on-link

To give a little more detail to that implementation bug, it seems the
host implementation inferred an on-link prefix from an address assigned
through DHCPv6.  We believe the implementation carried over
IPv4 behavior, in which it's common to pass on-link prefix information
to a host as a side effect of address assignment to interfaces.  In
IPv6, of course, RAs provide an explicit path for announcing prefix
information, so no prefix state should be inferred from address
assignment.

In my opinion, the "no PIO" case is adequately described in RFC 4861, as
the host has no information about on-link status of a prefix if there is
no PIO for that prefix.  Therefore, the host should send any outbound
traffic to an address from a prefix for which the host has not received
a PIO to the default router.

- Ralph

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Dec 2007 23:39:59 +0100

As you've already entered in this topics, according to DHCPv6 address
assignment users the current situation where on links without RAs or
with RAs without PIOs can be solved into two bad ways:
 - assume a 128 bit prefix length: not incorrect but surely inefficient
  so often qualified as stupid
 - assume a 64 bit prefix length: works almost everywhere but not
  everywhere so can be incorrect.
So please don't believe everybody happy with current DHCPv6...

Regards

[email-masked]

PS: I've personally used DHCPv6 only for Prefix Delegation so I reflect
a concern from other people.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 5 Dec 2007 17:49:16 -0500

Francis - In my opinion, the important problem scenario is when the  
host has no on-link prefix information AND the host has no default  
router.  This is most likely to happen when there are no RAs (likely  
because there is no router on the link), and can also happen when  
there are no default routers in any received RAs.

I agree that there is an issue in this problem scenario and one  
solution would be to include prefix information in DHCPv6 messages.   
If v6ops or 6man were to determine that carrying prefix information in  
DHCPv6 is useful, the dhc WG would be happy to  define an appropriate  
extension to DHCPv6.

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 18:01:35 -0500

Erik,

I know how to configure off-link on a router. I was asking the
community. At least the people we pinged in the past in the community
didn't know how or didn't reply including Hesham.

How off-link is configured is described in section 2.1, and 2.2.1 of our
draft. Your explanation below for the section 2.1 is fine. As for the
off-link suggestion you make below for AdvOnLinkFlag=False, folks might
not agree with you on just setting L-bit in RA to be clear and off-link
is signaled. Here is one reason why. Snipped below is text from section
2.3 on our draft.

[An on-link bit of clear indicates nothing regarding on-link
determination. In section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11
(Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor
Discovery for IP Version 6 (IPv6)," March 2007.) [NDbis]": 

"...a Prefix Information Option with on-link flag set to zero conveys no
information concerning on-link determination and MUST NOT be interpreted
to mean that addresses covered by the prefix are off-link.... Prefixes
with the on-link flag set to zero would normally have the autonomous
flag set and be used by [ADDRCONF]."]

Did we miss anything in the interpretation of the text above from RFC
4861. This text is not clear.

Thanks.

Hemant

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 1:46 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]
Subject: Re: Off-link and on-link

Hemant Singh (shemant) wrote:
> like unicast, mcast, and anycast data forwarding rules etc.  The 
> closest I have found in IETF is what IETF calls as multi-link router.

> As I said in the presentation, let's forget the aggregation router. 
> The host implementation bug we found is reproduced in an Ethernet LAN 

    Erik

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 6 Dec 2007 11:21:16 +1000

> 4861. This text is not clear.

=> I tried to explain it in the meeting and on the list but clearly my
explanation is not getting through. Let me have another shot. There is no
flag in 4861 that says that an entire prefix is off-link. Instead, clearing
the L flag means that the host should not assume that an address derived
from this prefix is on-link. So what's the consequence of this? The
consequence is that the host should send all packets to the default router.
The same consequence as if the flag says the prefix is off-link. So if all
you want to do is make sure that a host avoids address resolution and sends
packets straight to the default router then make sure the L flag is clear.
In the absence of the PIO, the default behaviour is to send packets to the
default router. 

If none of this is clear please read Bernie's earlier response. I don't know
how to make it any clearer. 

Hesham

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 18:36:47 -0800

Hemant and I met this afternoon and he explained the details of what 
they've observed, which helped me a lot more than the discussion in the 
WG meeting.

Based on this I think I understand the root cause of why some 
implementors get some things wrong.

The IPv6 subnet model is quite different than IPv4 in that it is 
optional to have any subnet prefix. In IPv4 there is always a subnet 
prefix associated an IP address (at least on anything but a 
point-to-point link).

While one can *infer* this from all of the text in RFC 4861, it might 
make sense to have an RFC which
  - makes this difference very explicit
  - gives examples of some implementation mistakes we've seen as a result

I don't think tweaking the text in RFC 4861 will necessarily help, since 
it gets lost in the volume of that RFC.

I told Hemant I'll help to make sure that high-level explanatory text is 
included.

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 21:59:49 -0500

Folks,

It was a pleasure to meet Erik face to face and chat - I also appreciate
his time. 

We have already agreed about 4 months back with Jari that we are not
suggesting any tweaking of text in RFC 4861 via our 3rd draft 
(http://www.ietf.org/internet-drafts/draft-wbeebee-nd-updates-00.txt) -
my slides also said, we are not actively pursuing any updates to be made
to RFC 4861 - I also agree with Erik the updates would get lost in the
sheer volume of that RFC; our updates draft should not be even the
subject of discussion for 6man.

We only wanted folks to especially read the first draft
(http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-
determination-00.txt) that makes interesting reading in just the items
1-7 of section 2. Some items in the list highlight IPv4 centric mind-set
of implementations. Right now we just have very explicit text in this
on-and-off-link draft for IPv6 mistakes. Erik's suggestion is well-taken
that we could also explain the differences with IPv4 in these cases we
discuss.  

On another note, the example that Fred Baker gave in his IPv6 SAVI BOF
for spoofing gotchas is listed as an example scenario in item 5 of
section 3 of our on-and-off-link draft mentioned in the URL above. We
presented this example to 2462bis-8 as a scenario to show why skipping
DAD did not make sense. 

I and Wes will work with Erik to make some high-level explanatory text
available. 

Thanks very much Erik. Also thanks to all who replied on the thread.

Hemant

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 6:37 PM
To: [email-masked]
Cc: Hemant Singh (shemant); Suresh Krishnan
Subject: Re: Off-link and on-link

While one can *infer* this from all of the text in RFC 4861, it might
make sense to have an RFC which
  - makes this difference very explicit
  - gives examples of some implementation mistakes we've seen as a
result

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 22:34:45 -0500

Ralph and other DHCPv6 folks,

Sorry, if I missed the deployment model where there is no router on the
link. Could you please articulate what commercially deployed IPv6
services will not include an IPv6 router?

Thanks.

Hemant

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, December 05, 2007 2:49 PM
To: Francis Dupont
Cc: Hemant Singh (shemant); Erik Nordmark; IPV6 List Mailing; Suresh
Krishnan

Francis - In my opinion, the important problem scenario is when the host
has no on-link prefix information AND the host has no default router.
This is most likely to happen when there are no RAs (likely because
there is no router on the link), and can also happen when there are no
default routers in any received RAs.

- Ralph

> PS: I've personally used DHCPv6 only for Prefix Delegation so I 
> reflect a concern from other people.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 9 Dec 2007 16:12:24 -0500

Ralph,

Not quite. The bug was also seen when the host was asked to do SLAAC.
Since neither, I, you, nor Erik have access to this host's source code,
we can never tell for certain what caused the host to issue NS for
address resolution when the router DID NOT signal on-link to the host. I
do agree we found multiple bugs in the host's IPv6 implementation and
that is what has caused us to some rules in section 2 of our
on-and-off-link draft.

Hemant 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, December 05, 2007 4:27 PM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; IPV6 List Mailing; Suresh Krishnan
Subject: Re: Off-link and on-link

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Dec 2007 12:56:57 -0500

Erik,

I am getting back to replying to some emails that were sent in response
to our drafts. I did explain what an aggregation router was when we met
face to face at IETF. If you had read our drafts, that was one way to
learn about properties of an aggregation router wrt to ND. It was
unfortunate, neither you or Hesham had read our drafts when folks like
Jinmei Tatuya, Alain Durand, Jari, and Vlad have. 

Anyhow, RFC 4388 mentions an access concentrator. When this concentrator
supports routing, the device is an aggregation router.

Hemant

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 3:29 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]
Subject: Re: Off-link and on-link

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Dec 2007 13:12:13 -0500

Hesham,

This is what you have said below that I have put inside double quotes:

"Instead, clearing the L flag means that the host should not assume that
an address derived from this prefix is on-link."

My response to this statement is below. I have snipped text from RFC
4861 below (within square brackets)

[Note, however, that a Prefix Information option

Narten, et al.              Standards Track                    [Page 54]
 
RFC 4861               Neighbor Discovery in IPv6         September 2007

   with the on-link flag set to zero conveys no information concerning
   on-link determination and MUST NOT be interpreted to mean that
   addresses covered by the prefix are off-link.]

The text from RFC is saying the receiver of such an RA cannot assume
addresses covered by the prefix are off-link while your statement above
says cannot assume on-link. 

Now, if I go by this text in the RFC, I as a host WILL NOT send traffic
to the default router because I cannot assume off-link. 

Hemant

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 8:21 PM
To: Hemant Singh (shemant); 'Erik Nordmark'
Cc: [email-masked]; 'Suresh Krishnan'
Subject: RE: Off-link and on-link

 > I know how to configure off-link on a router. I was asking the  >
community. At least the people we pinged in the past in the community  >
didn't know how or didn't reply including Hesham.
 >
 > How off-link is configured is described in section 2.1, and  > 2.2.1
of our  > draft. Your explanation below for the section 2.1 is fine. As
for the  > off-link suggestion you make below for AdvOnLinkFlag=False,
> folks might  > not agree with you on just setting L-bit in RA to be
clear  > and off-link  > is signaled. Here is one reason why. Snipped
below is text  > from section  > 2.3 on our draft.
 >
 > [An on-link bit of clear indicates nothing regarding on-link  >
determination. In section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11  >
(Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor  >
Discovery for IP Version 6 (IPv6)," March 2007.) [NDbis]": 
 >
 > "...a Prefix Information Option with on-link flag set to  > zero
conveys no  > information concerning on-link determination and MUST NOT
be  > interpreted  > to mean that addresses covered by the prefix are  >
off-link.... Prefixes  > with the on-link flag set to zero would
normally have the autonomous  > flag set and be used by [ADDRCONF]."]  >

=> I tried to explain it in the meeting and on the list but clearly my
explanation is not getting through. Let me have another shot. There is
no flag in 4861 that says that an entire prefix is off-link. Instead,
clearing the L flag means that the host should not assume that an
address derived from this prefix is on-link. So what's the consequence
of this? The consequence is that the host should send all packets to the
default router.
The same consequence as if the flag says the prefix is off-link. So if
all you want to do is make sure that a host avoids address resolution
and sends packets straight to the default router then make sure the L
flag is clear.
In the absence of the PIO, the default behaviour is to send packets to
the default router. 

If none of this is clear please read Bernie's earlier response. I don't
know how to make it any clearer. 

Hesham

 > From: Erik Nordmark [mailto:[email-masked]]  > Sent:
Wednesday, December 05, 2007 1:46 PM  > To: Hemant Singh (shemant)  >
Cc: Suresh Krishnan; [email-masked]  > Subject: Re: Off-link and on-link
 > > Good question, Erik. To the best of my knowledge such an  > RFC
does not  > > exist - at least describing total details of an  >
aggregation router -  > > like unicast, mcast, and anycast data
forwarding rules etc.  The  > > closest I have found in IETF is what
IETF calls as  > multi-link router.
 > > Now the question I asked in my presentation. I have to  > configure
this  > > aggregation router to signal off-link. How do I do that?
 > > As I said in the presentation, let's forget the  > aggregation
router. 
 > > The host implementation bug we found is reproduced in an  >
Ethernet LAN  > > network too. An RA from the router was sent where RA
was  > NOT signaling  >  > > on-link and the host still behaved as
on-link for traffic  > forwarding.
 > > The RA we used was an RA that did not send any PIO (Prefix  >
Information  >  > > Option). BTW, such a case (RA with no PIO) is not
even  > covered by the  > > definition of on- and off-link in section
2.1 of RFC 4861,  > especially  > > since section 2.1 goes to so much
copious details to  > describe on-link.
 >
 > It does cover it. If no information is know about an address  >
(which is  > this case - no prefix options with L=1 and no redirects)  >
then the host  > will send to a default router.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Dec 2007 15:09:12 -0500

BTW Hesham,

I understand what the behavior is for on-link and off-link; L=0 is a
no-op and if the prefix exists in prefixList, the L-bit of the prefix
remains unchanged; only a L=1 with Valid Lifetime = 0 signals cancels an
existing on-link prefix. I sent this email to only show that text can be
confusing in RFC 4861.

As Josh Littlefield also said the other day, the language is not crystal
clear. We wanted clearer text that said that default assumption is that
all prefixes are off-link, and this means send to default router. Only
reception of L=1 can change that for any specific prefix. You all can
read rest of this text.

We want to have our draft clarify all such text - please read it. We do
clarify a lot more issues in our draft. Do also note our on-and-off-link
draft is on Standards Track - we are not interested in changing its
nature to Informational because our draft has too many MUST's that we'd
like to keep.

Hemant 

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Wednesday, December 12, 2007 1:12 PM
To: Hesham Soliman; Erik Nordmark
Cc: [email-masked]; Suresh Krishnan
Subject: RE: Off-link and on-link

Hesham,

 

Hemant

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]]
Sent: Wednesday, December 05, 2007 8:21 PM
To: Hemant Singh (shemant); 'Erik Nordmark'
Cc: [email-masked]; 'Suresh Krishnan'
Subject: RE: Off-link and on-link

Hesham

router.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Dec 2007 15:17:14 -0500

Hesham,

Since you said it's good to highlight such DHCPv6 facts to
implementations, see our 2nd draft.

http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-prob
lems-00.txt

where we have highlighted such implementation issues. See section 2.3 of
this draft. Further, bullet 2 in section 2 of our on-and-off-link draft
highlight this DHCPv6 client mistake in a rule.
 
Could we get a rough consensus if the above draft should be a work item
of 6man? Folks have to read the draft first. So far only Jinmei and Vlad
have reviewed the implementation draft. 

We can debate the on-and-off-link draft separately.

Thanks.

Hemant

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 5:32 PM
To: Ralph Droms (rdroms); Hemant Singh (shemant)
Cc: 'Erik Nordmark'; 'IPV6 List Mailing'; 'Suresh Krishnan'
Subject: RE: Off-link and on-link

 > To give a little more detail to that implementation bug, it  > seems
the  > host implementation inferred an on-link prefix from an address  >
assigned through DHCPv6.  We believe the implementation  > carried over
> IPv4 behavior, in which it's common to pass on-link prefix  >
information  > to a host as a side effect of address assignment to
interfaces.  In  > IPv6, of course, RAs provide an explicit path for
announcing prefix  > information, so no prefix state should be inferred
from address  > assignment.

=> Exactly. This makes sense, and it's good to highlight that to
implementations, I just don't think this behaviour is a result of
correct reading of the spec.

 >
 > In my opinion, the "no PIO" case is adequately described in  > RFC
4861,  > as the host has no information about on-link status of a prefix
if  > there is no PIO for that prefix.  Therefore, the host should  >
send any  > outbound traffic to an address from a prefix for which the
host has  > not received a PIO to the default router.

Hesham

router.  
> > network too. An RA from the router was sent where RA was  > NOT
signaling  > > on-link and the host still behaved as on-link for traffic
> forwarding.
Information  > > Option). BTW, such a case (RA with no PIO) is not even
> covered by the  > > definition of on- and off-link in section 2.1 of
RFC 4861,  > especially  > > since section 2.1 goes to so much copious
details to  > describe on-link.
 > > From: Erik Nordmark [mailto:[email-masked]]  > > Sent:
Wednesday, December 05, 2007 12:29 PM  > > To: Hemant Singh (shemant)  >
> Cc: Suresh Krishnan; [email-masked]  > > Subject: Re: Off-link and
on-link  > >  > > Hemant Singh (shemant) wrote:
> >> aggregation routers do not send Redirects. So the scenario below  >
 > >> Sent: Wednesday, December 05, 2007 11:01 AM  > >> To:
[email-masked]  > >> Subject: Off-link and on-link  > >>  > >> Hi
Hesham/Dave/Erik,  > >>  I am not taking a stand on whether an explicit
off-link flag is  > >> necessary/useful or not, but I have encountered a
> scenario where the  > >> existing algorithm specified in RFC4861 does
not work very well.  
 > >> Let's
 > >
 > >> say a router wants to signal to the clients that  >
2001:dead:beef::/48  > >> is on-link except for 2001:dead:beef:abcd::/64
that is  > off-link. How  > >> would it go about describing this? I see
two ways  > >>  > >> a) Advertise the /48 with L=0 and send redirects
for all  > addresses  > >> not  > >  > >> on the /64  > >> b) Advertise
the /48 with L=1 and the /64 with Q(the new off-link  > >> flag)=0  > >>
> >> I see b) as being more efficient than a)  > >>  > >> P.S: I do not
think that this scenario is very likely,  > just possible.
 > >> IETF IPv6 working group mailing list  > >> [email-masked]  > >>
Administrative Requests: 
 > >> IETF IPv6 working group mailing list  > >> [email-masked]  > >>
Administrative Requests: 
 > > IETF IPv6 working group mailing list  > > [email-masked]  > >

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 13 Dec 2007 10:57:47 +1000

> unfortunate, neither you or Hesham had read our drafts when 

=> Would you please not attribute things to me? I did read the draft before
I commented in the meeting. I don't know why you keep repeating this. 

Hesham

 > folks like
 > addresses not

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Dec 2007 21:18:45 -0500

Hemant - I've reviewed this version of your draft as well as (as you  
know) earlier versions.  I don't have a clear preference about whether  
or not to take this draft on as a WG work item.  It would be helpful  
to have a record of these implementation problems.  However, my  
understanding is that each of problems 2.1, 2.2 and 2.3 (and I think  
2.1 and 2.3 are related) has been found once and has been or will be  
patched.  Will the WG want to begin a collection of similar bugs found  
in other stacks?

Is there text in an RFC that can be used as the basis for  
demonstrating 2.4 is an explicit bug?

- Ralph

On Dec 12, 2007, at Dec 12, 2007,3:17 PM, Hemant Singh (shemant) wrote:

> the /48 with L=1 and the /64 with Q(the new off-link  > >> flag)=0   
> > >>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Dec 2007 21:29:49 -0500

Hemant - From RFC 4861, I interpret the definition of "prefix list"  
and the text in section 5.2 to mean that:

* if the host has received an RA containing a PIO with L=0, it
   adds that prefix to its prefix list; when sending a datagram to
   an address from that prefix, the host finds the prefix in
   its prefix list and delivers the datagram directly to the
   destination
* otherwise, the host will not ever add the prefix to its
   prefix list; when sending a datagram to an address from that
   prefix, the host does not find the prefix in its prefix list
   and delivers the datagram to its default router

Therefore, I interpret the decision to be "on-link, deliver direct;  
otherwise, send to default router".  The specs are not written to  
include a rule for an explicit "off-link, send to default router"  
decision.

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Dec 2007 03:36:11 -0500

I think you meant L=1 as the text in 6.3.4. Processing Received Router
Advertisements only gives explicit instructions to the host for PIOs
where L=1. It has NO instructions as to what the host does with a PIO
with L=0. So, one would assume that they are ignored (and thus fairly
useless to be sent by a router at least in terms of
on-link/not-on-link).

In section 5.2, the text is very clear as to what a host does:

   Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List (following the rules
   described in Section 6.3.6).

Here this "longest prefix match" means that the PIO w/L=0 would not be
on the Prefix List (per the 6.3.4 text which lacks any instructions
about doing anything with these PIOs) and hence if there wasn't another
match, the prefix would be assumed as being "off-link".

And, RFC 4861 also clearly defines that the "Prefix List" only contains
on-link prefixes:

      Prefix List  - A list of the prefixes that define a set of
                     addresses that are on-link.  Prefix List entries
                     are created from information received in Router
                     Advertisements.  ...

This is actually very interesting as it clearly implies that PIO w/L=0
are ignored (in terms of the Prefix List). And, if the PIO has L=0 and
A=0 (considering RFC 4861 & 4862), the router is just wasting network
bandwidth and host processing time by sending that PIO.

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, December 12, 2007 9:30 PM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; [email-masked]; Suresh Krishnan; Ralph Droms (rdroms)
Subject: Re: Off-link and on-link

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Dec 2007 09:09:31 -0500

Bernie - yes, "L=0" is a typo and should have read "L=1".

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 13 Dec 2007 10:08:34 -0500

Ralph,

Vendors seem to have been testing IPv6 with only on-link prefixes
including our own company in Cisco. Soon as we guys in Cisco began
testing IPv6 in off-link mode, bugs in hosts began showing up. These
off-link tests don't even exist in TAHI IPv6 host tests but TAHI has
certified hosts as IPV6 ready :-). If not for any other reason, 6man
should document these bugs in the format of RFC 2525 and let TAHI write
up new test cases. In the past six months, I have contacted TAHI but the
process with them seems slow. They still haven't added our test cases
for off-link in their test suite for IPv6 hosts. Bugs 2.1 and 2.3 do
need to be added to TAHI. 

As for 2.1 and 2.3 may be related or may not - we don't have access to
the source code of this host. Do note 2.1 and 2.3 are two distinct bugs
in the host. 2.1 is host assuming on-link for a destination when host
should have assumed off-link. This is the case when router sent the host
an RA with no PIO. 

2.3 is incorrect host behavior for adding a route based on host using an
invented prefix (assuming a default prefix length) that is partially
derived from the acquired DHCPv6 address.

As for 2.4, when I explained to Erik in the hallway at IETF as to what
an aggregation router behavior is, he explained to me that this router
behavior maps to a point-to-point link. I agree with him. Such a link is
well-known to the community.  Anyhow, data behavior properties of an
aggregation router are also discussed in our on-and-off-link draft. Our
on-and-off-link draft explains the behavior in section 3.1 and 4. My
IETF presentation also said subscribers behind modems in an aggregation
router are always off-link (IPv4 or IPv6). These subscribers cannot talk
directly to each other. So the aggregation router which is also the IPv6
default router is lying to any subscriber if this router sends Redirects
to the subscriber because such subscribers cannot talk directly to each
other. There is one exception to this case which is explained in
following text snipped from section 4 of our draft(in square brackets):

[Redirects are not sent by aggregation routers except when two hosts
behind the same bridge CPE, with no router between the host and the
aggregation router, communicate with each other. The aggregation router
sends a Redirect to a source host which communicates with a destination
host behind the same bridge CPE if the router can make a determination
that the two hosts lie behind the same bridge CPE.]

When I explained to Erik he understood this aggregation router behavior
in a jiffy. Aggregation routers do not send Redirects - this behavior
falls out from the fact that subscribers are off-link in an aggregation
network.

As a reminder, both 2.1 and 2.3 bugs are reproducible in an Ethernet LAN
too. These bugs have nothing to do with an aggregation router although
this router is an excellent device to test off-link for IPv6 with.

A record of the problems makes sense because now there are IPv6
implementations being developed from scratch in consumer devices which
have very limited memory to leverage a free BSD or Linux IPv6 stacks.
Such stacks are being developed from scratch. I have already
interoperated IPv6 with one such device in the past year. We need a
strict set of rules for IPv6 data forwarding and on-and-off-link.

Hemant

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, December 12, 2007 9:19 PM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); Hesham Soliman; Erik Nordmark; IPV6 List
Mailing; Suresh Krishnan

Hemant - I've reviewed this version of your draft as well as (as you
know) earlier versions.  I don't have a clear preference about whether
or not to take this draft on as a WG work item.  It would be helpful to
have a record of these implementation problems.  However, my
understanding is that each of problems 2.1, 2.2 and 2.3 (and I think
2.1 and 2.3 are related) has been found once and has been or will be
patched.  Will the WG want to begin a collection of similar bugs found
in other stacks?

Is there text in an RFC that can be used as the basis for demonstrating
2.4 is an explicit bug?

- Ralph

On Dec 12, 2007, at Dec 12, 2007,3:17 PM, Hemant Singh (shemant) wrote:

> this draft. Further, bullet 2 in section 2 of our on-and-off-link 
> draft highlight this DHCPv6 client mistake in a rule.
>
> Could we get a rough consensus if the above draft should be a work 
> item of 6man? Folks have to read the draft first. So far only Jinmei 
> and Vlad have reviewed the implementation draft.
>
> the  > host implementation inferred an on-link prefix from an address

> announcing prefix  > information, so no prefix state should be 
> inferred from address  > assignment.
>
> 4861,  > as the host has no information about on-link status of a 
> prefix if  > there is no PIO for that prefix.  Therefore, the host 
> should  > send any  > outbound traffic to an address from a prefix for

> which the host has  > not received a PIO to the default router.
>

> Hesham/Dave/Erik,  > >>  I am not taking a stand on whether an 
> explicit off-link flag is  > >> necessary/useful or not, but I have 
> encountered a
> that is  > off-link. How  > >> would it go about describing this? I 
> see two ways  > >>  > >> a) Advertise the /48 with L=0 and send 
> redirects for all  > addresses  > >> not  > >  > >> on the /64  > >> 
> b) Advertise

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 13 Dec 2007 10:33:04 -0500

Hesham,

OK, if you read the draft(s), my apologies. Sorry if you said so in the
IETF meeting too and I missed the fact.

However, I have one question. If you read the drafts, which of the
following four have you read?

http://www.arkko.com/tools/allstats/hemantsingh.html 

So far folks who read our drafts also sent comments to the IETF mailers.
Jinmei and Vlad to ipv6 IETF mailer and Alain Durand to the IETF DHC
mailer.
 
Thanks.

Hemant

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, December 12, 2007 7:58 PM
To: Hemant Singh (shemant); 'Erik Nordmark'
Cc: [email-masked]; 'Suresh Krishnan'
Subject: RE: Off-link and on-link

 >
 > I am getting back to replying to some emails that were sent  > in
response  > to our drafts. I did explain what an aggregation router was
> when we met  > face to face at IETF. If you had read our drafts, that
was one way to  > learn about properties of an aggregation router wrt to
ND. It was  > unfortunate, neither you or Hesham had read our drafts
when 

=> Would you please not attribute things to me? I did read the draft
before I commented in the meeting. I don't know why you keep repeating
this. 

Hesham

 > Anyhow, RFC 4388 mentions an access concentrator. When this  >
concentrator  > supports routing, the device is an aggregation router.
 > From: Erik Nordmark [mailto:[email-masked]]  > Sent:
Wednesday, December 05, 2007 3:29 PM  > To: Hemant Singh (shemant)  >
Cc: Suresh Krishnan; [email-masked]  > Subject: Re: Off-link and on-link
 > > Sent: Wednesday, December 05, 2007 11:01 AM  > > To: [email-masked]
> > Subject: Off-link and on-link  > >  > > Hi Hesham/Dave/Erik,
 > > necessary/useful or not, but I have encountered a scenario  > where
the  > > existing algorithm specified in RFC4861 does not work very  >
well. Let's  >  > > say a router wants to signal to the clients that  >
2001:dead:beef::/48  > > is on-link except for 2001:dead:beef:abcd::/64
that is  > off-link. How  > > would it go about describing this? I see
two ways  > >  > > a) Advertise the /48 with L=0 and send redirects for
all  > addresses not  >  > > on the /64  > > b) Advertise the /48 with
L=1 and the /64 with Q(the new off-link  > > flag)=0  > >  > > I see b)
as being more efficient than a)  > >  > > P.S: I do not think that this
scenario is very likely,  > just possible.