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
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; ipv6@ietf.org
> 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: ipv6@ietf.org
>> 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
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
