Hello, Teemu. A few comments are added below.
2008/10/23 <[EMAIL PROTECTED]>: > Hi, > > Used link-layer does have an impact: on cellular networks the link-layer is > nowadays most often opened on-demand (i.e. when an application starts), or > quickly reopened e.g. if network connection is temporarily lost for any > reason. In the future always-on connectivity becomes more commonplace than it > is today, but temporal connection failures may remain in game.. So, when a > connection is (re-)opened, IPv6 address needs to be obtained as quickly as > possibly for the reasons of good user experience (user is waiting for > something to happen..). Often the connection is trusted point-to-point > connection, so there is no risk of spoofed RAs. As user is waiting, there is > no time to start guessing whether DHCP is available or not, but address will > be configured by fastest means available - currently by sending RS > immediately when link layer gets up to ensure fastest possible retrieval of > RA. > If delay time for address configuration is crucial for user, how about DNS or other configuration informations? Are those informations provisioned through stateless DHCPv6? Now, I guess that stateless DHCPv6 is initiated right after the first RA is received with O flag set to 1. Is this delay acceptable for your environment? Joseph > Best regards, > > Teemu > >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>On Behalf Of ext Dunn, Jeffrey H. >>Sent: 17 October, 2008 17:20 >>To: TJ; IPV6 List Mailing >>Cc: DHC WG; Dunn, Jeffrey H. >>Subject: Re: [dhcwg] Brokenness of specs w.r.t. client >>behavior with M&O bits >> >>I have been lurking on this discussion for a while and have >>one observation. Regardless of the values of the M&O bits or >>the prefixes (and their lengths) that are advertised, I >>suggest that the client not >>send any messages until it receives a "General Query (RFC 3810)." If >>the client does not hear a GQ within a suitable time (either >>TBD or SOL_TIMEOUT, etc per RFC 3315), I suggest that the >>client "assumes" >>that no DHCPv6 server is available. This goes a short way to >>preventing the simplest RA (here meaning router advertisement, >>NOT relay agent) spoofing. >> >>Thoughts? >> >>Best Regards, >> >>Jeffrey Dunn >>Info Systems Eng., Lead >>MITRE Corporation. >>(301) 448-6965 (mobile) >> >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>Behalf Of TJ >>Sent: Friday, October 17, 2008 9:07 AM >>To: 'IPV6 List Mailing' >>Cc: 'DHC WG' >>Subject: RE: [dhcwg] Brokenness of specs w.r.t. client >>behavior with M&O bits >> >>Not trying to oversimplify things here, but to me it makes the >>most sense to start with what we have working now and *not* >>make any broad, sweeping changes. To do otherwise is not only >>a tremendous disservice to all of those who have >>implemented/adopted IPv6 (or are considering doing so) but >>also fails IMHO to be a good, technical approach to the >>problem at hand. >> >>I am in no way saying we can't continue adding capabilities >>(e.g. - XML config via RA-provided URL) ... but to make >>drastic changes to functions that real people are using in >>real networks to provide real services seems, well, sub-optimal. >> >> >>What we have: >> SLAAC >> Stateless DHCPv6 >> Stateful DHCPv6 >> (Manual Configuration, out of scope for / irrelevant to this >>conversation) >> >> >>SLAAC is well defined, and works quite well - even w/o >>DNS-option support being widespread. Once RFC5006 support is >>in place, this will be sufficient for most uses, with a valid >>concern about the host identification / >>(dynamic) name resolution areas. We can address those, rather >>than toss the baby with the bath water. >> >>DHCPv6 is also well defined, with some questions rising around >>the acillary pieces - e.g. when does a host run it, and choose >>which mechanism. >>IMHO, >>simply making a clearer definition of the M & O bits would be >>sufficient. >> >> >>In my world view, the following would be the least painful and >>most functional approach: >> Host sends RS >> If RA recevied - look for A/prefix, M, O bits and act >>accordingly. >> ... if one RA specifies one approach, and one >>RA specifies the another, do both ... >>In almost all properly functioning scenarios this is all the >>we need, yes? >> >> >>Additionally ... >> If no RA received, I am OK with the host making a >>one-shot attempt at both stateless and stateful DHCP, just in case >> ... the question here - what is the assumed >>prefix length / "on link" approach? >> ... if we stick with the "right" answer >>of /128, well then DHCPv6 didn't accomplish much >> ... unless something else comes >>in to play >> ... LLMNR, etc. >>providing a >>hint on onlinkedness, or somesuch. >> ... if we assume /64 we raise other >>problems / questions >> I think this case is somewhat degenerate and >>should be rare; but should nonetheless have a consistent, well >>defined behavior. >> >> >> >>Am I missing anything fundamental here? >>/TJ >> >>PS - I totally agree with Iljitsch's "the amount of people >>that complain that IPv6 changes too much seems to be about the >>same as those that complain that IPv6 doesn't change enough so >>my guess is that they got this more or less right" ... I >>believe another relevant quote would be "rough consensus and >>running code". >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >>_______________________________________________ >>dhcwg mailing list >>[EMAIL PROTECTED] >>https://www.ietf.org/mailman/listinfo/dhcwg >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
