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.
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
>[email protected]
>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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
