-----Original Message----- From: Ralph Droms (rdroms) Sent: Friday, June 29, 2007 12:06 PM To: Stig Venaas Cc: Hemant Singh (shemant); JINMEI Tatuya / ????; IETF Mailing List IPv6 Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08
Hemant - does RFC 2461 allow a host to ignore the PIOs in RAs? <hs> Not that I know of. Stig - you wrote "At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on- link determination. I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen." I can understand that it should be possible to manually configure on-link prefix information. I question whether that configuration should be conceptually tied with address assignment because of the design of IPv6, or do we mix address assignment with prefix information because that's the way it was done in IPv4? Looking back to the definition of DHCPv6 - we received a lot of input that DHCPv6 should *not* include information about default routers and on-link prefixes, because that information comes from RAs. That argument made sense to me at the time; makes sense to me in the case of manual address assignment, too... <hs> Sure thing. But how does a sys admin who is configuring IPv6 manually on a host know what has RA sent to the host to match setting on the host with the RA? Is it the same admin who also has access to the IPv6 default router for this host in which case the admin know how has ND and RA been configured on the router. Even if admin knows how is RA configured on router, the admin can fat-finger the default prefix and prefix length during manual configuration. Or of admin doesn't have access to the router's config, the admin has to sniff RA in the network and see what PIO has been sent etc. This seems like a process prone to errors. Hemant - Ralph On Jun 29, 2007, at Jun 29, 2007,11:53 AM, Stig Venaas wrote: > Hemant Singh (shemant) wrote: >> Please see in line below with "<hs>" >> >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: Friday, June 29, 2007 10:26 AM >> To: JINMEI Tatuya / ???? >> Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh >> (shemant) >> Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with >> urgent changessuggested to 2462bis-08 >> >> >> On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / 神 >> 明達哉 >> wrote: >> >>> At Wed, 27 Jun 2007 14:27:37 -0400, >>> Ralph Droms <[EMAIL PROTECTED]> wrote: >>> >>>> One bug that may or may not be common is to make assumptions about >>>> the prefixes on a link based on addresses assigned to an interface. >>>> I can imagine (and I believe we've actually made a real sighting of >>>> this scenario) that an IPv6 implementor might extrapolate IPv4 >>>> conventions and extract the /64 prefix from an assigned address >>>> (either SLAAC, DHCP or manual config), and add a route to the host >>>> table indicating that the prefix is on-link, regardless of whether >>>> the prefix is advertised as "on-link" in an RA. >>> [...] >>> >>> If the system administrator manually configures an IPv6 address >>> with a >>> prefix length smaller than 128, the kernel will assume that the >>> corresponding prefix is on-link. But I believe this should be >>> reasonable. >>> >>> JINMEI, Tatuya >>> Communication Platform Lab. >>> Corporate R&D Center, Toshiba Corp. >>> [EMAIL PROTECTED] >> >> I see where draft-wbeebee-nd-implementation-pitfalls also mentions >> manual configuration as a special case: >> >> 2. The RA and ICMPv6 Redirects from the default router are >> the only >> sources of information 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 >> document. >> >> Is there some reason to believe the information about on-link >> prefixes should be implicitly overridden in the case of manual >> address assignment? I can understand explicitly overriding >> information from RAs by manually configuring the on-link >> information as a separate step from manual address assignment. >> But it seems to me that assuming the prefix from a manually >> configured address is on- link might cause unexpected loss of >> connectivity if the prefix does require off-link delivery through >> the router. > > At least as a sysadmin/user I would find it confusing if the prefix > length I configured would not be used for on-link determination. > > I think it's more bad than good to try to separate the two. I'm > happy the way it currently is on the systems I've seen. > >> >> <hs> If the host has been manually configured for IPv6 address >> where the host was also configured for prefix and prefix length, >> then what's on-link for this host can be determined by host. But >> what if manual configuration configured an IPv6 address and maybe, >> also the prefix, but forgot to configure prefix length. Then this >> manual configuration has no means to determine what's on-link for >> a destination based on the data from manual configuration. I have >> host not assuming a default prefix length yet. The RA has been >> explicitly ignored. So not this host has no choice but to send non- >> link-local traffic to the default router. Specifying manual >> configuration behavior and its interaction with RA is a can of >> worms that will take time to clear up. > > Can you manually configure prefix on a host without also specifying > prefix length? > > Stig > >> >> Hemant >> >> - Ralph >> >> >> -------------------------------------------------------------------- >> 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 --------------------------------------------------------------------
