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 PROTECTED]
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.
=> Agreed. That's the default behaviour.
Hesham
- Ralph
On Dec 5, 2007, at Dec 5, 2007,4:05 PM, Hemant Singh (shemant) wrote:
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 PROTECTED] > > Sent:
Wednesday, December 05, 2007 12:29 PM > > To: Hemant Singh
(shemant) >
Cc: Suresh Krishnan; [email protected] > > Subject: Re: Off-link and
on-link > > > > Hemant Singh (shemant) wrote:
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.
Which RFC defines an "aggregation router"?
Erik
Hemant
-----Original Message-----
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 05, 2007 11:01 AM > >> To:
[email protected] > >> 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.
Cheers
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list > >> [email protected] > >>
Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list > >> [email protected] > >>
Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list > > [email protected] > >
Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
