Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt

From: "Elwyn Davies" <[email-masked]>
Date: Tue, 17 Aug 2004 15:37:43 +0100

Hi.

I'll try to clarify ... British reserve showing;-)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 17 August 2004 14:45
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: [email-masked]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
> 
> 
> Some quick clarifications:
> 
> >>>>> On Mon, 16 Aug 2004 18:43:04 +0100, 
> >>>>> "Elwyn Davies" <[email-masked]> said:
> 
> >> > The confusion around stateful, 3315 and 3736 has been 
> >> discussed at length
> >> > elsewhere.
> >> 
> >> Sorry, I don't understand the point.  Could you be more specific on
> >> what you want?
> 
> I guess you meant the following message:
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg03314.html
> 
> but I'm still not 100% sure about the point.
> 
> I hate to make a wild guess and continue the discussion based on the
> assumption, but if you mean it is confusing to tie the M/O flags with
> the notion of "stateful" protocols while RFC3736 calls itself
> "stateless", I tried to clarify this point in rfc2462bis:
> 
>    To obtain other configuration information without configuring
>    addresses in the stateful autoconfiguration model, a 
> subset of DHCPv6
>    [RFC3736] will be used.  While the model is called 
> "stateful" here in
>    order to highlight the contrast to the stateless protocol 
> defined in
>    this document, the intended protocol is also defined to work in a
>    stateless fashion.  This is based on a result, through operational
>    experiments, that all known "other" configuration 
> information can be
>    managed by a stateless server, that is, a server that does not
>    maintain state of each client that the server provides with the
>    configuration information.
> 
> Note that this is a compromise with the real world standardization
> status.  Perhaps you are not 100% comfortable with the compromise (I'm
> not, actually), we needed to face that RFC3736 was already
> standardized and people do not want to change the phrase "stateful" in
> rfc2461bis/rfc2462bis.  I could not think of better compromise...

I am not totally happy with the compromise but I understand what you are
trying to do.

I think the words  in s.1 (quoted above) are fine given the reluctance to
change things any more.

The piece that (still) struck me as potentially confusing was the abstract
where the title of RFC 3736 might be read before your explanation in s.1.
Perhaps the last sentence of the abstract could be expanded to express the
compromise.  How about:
The details of autoconfiguration using the stateful protocol are specified
in RFC 3315; an alternative way of using the stateful protocol to deliver
'other information' only is specified in RFC 3736.

Hope this clears this up.

> 
> >> > s.5.5.3: Should the logic on updating address lifetimes in 
> >> item (e) be
> >> > applied to addresses configured by stateful and/or other 
> >> means?  Equivalent
> >> > DOS attacks could come from (bogus)server initiated DHCP 
> updates as
> >> > described in the Security considerations of RFC3315 .
> >> 
> >> We've intentionally eliminated the case of addresses configured by
> >> DHCPv6 for several reasons:
> >> 
> >> - we basically concentrate on stateless address 
> configuration, and the
> >> detailed description of the stateful case is left to other
> >> documents.
> >> - the description of Section 5.5.3 cannot easily apply to DHCPv6,
> >> since Section 5.5.3 depends on the notion of the "prefix length" of
> >> an address while DHCPv6 does not convey the information.
> >> 
> >> One more point.  I'm not sure what you meant by "as 
> described in the
> >> Security considerations of RFC3315", but DHCPv6 has its 
> own security
> >> mechanism, and, in my understanding, the "official" 
> position to DHCPv6
> >> spoofing attacks is "use DHCPv6 authentication".
> 
> > You are quite right - the DHCPv6 Reconfigure messages are 
> required to be
> > authenticated which reduces the risk here.  Incidentally, I was not
> > suggesting that all of 5.5.3 was applicable to 
> DHCP-acquired addresses, only
> > that it might be sensible to apply the Valid Lifetime 
> constraints to other
> > addresses than those constructed by stateless autoconfig. 
> 
> So I interpret this to mean this is a non issue in rfc2462bis.

Right. Issue closed.

Thanks for your consideration.

Regards,
Elwyn
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 Aug 2004 20:02:29 +0900

>>>>> On Tue, 17 Aug 2004 15:37:43 +0100, 

> 'other information' only is specified in RFC 3736.

Sounds good.  I'll use the suggested text in the abstract.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]