Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition

[Jonathan Rosenberg <[e-mail]>]

inline.

Jean-Francois Mule wrote:

> Jonathan Rosenberg wrote:
> 
>>>>3. be much simpler than ICE-full for dual-stack endpoints that are
>>
>>not
>>
>>>>natted
>>>
>>>After reading a few drafts and archives in the v6ops group (old and
>>>current), there are known limitations of 3484 and many proposals on
>>
>>how
>>
>>>the address selection mechanism should be updated or improved to
>>>ultimately guarantee connectivity. This goes beyond the NAT cases,
>>
>>and
>>
>>>it is sometimes applicable to multi-homed v6 nodes, etc.
>>>
>>>References:
>>>http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03
>>>http://tools.ietf.org/html/draft-arifumi-v6ops-addr-select-ps-01
>>>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-
>>
>>req-01.
>>
>>>txt
>>>http://www.ops.ietf.org/lists/v6ops/v6ops.2004/msg01072.html
>>>
>>>When I read your proposal trying to connect the dots between this
>>
>>thread
>>
>>>and the above v6ops references (looking at it as someone deciding
>>
>>what
>>
>>>to implement in a dual-stack host given the current state of the
>>
>>art),
>>
>>>it seems to me that with ICE, we have a mechanism to resolve those
>>>potential 3484 issues by doing connectivity checks. Yet, we're about
>>
>>to
>>
>>>say, no, just do ICE-lite+ and no connectivity checks.
>>
>>No, I'm not saying that. I'm saying, if you think you can deal with
>>the
>>following limitations A,B, and C, then use ice-lite. Otherwise, use
>>full, and full is always better.
>>
>>In the case of dual-stack, I don't follow v6ops, so if you could
>>provide
>>some text that I could include in ICE, summarizing limitations, giving
>>some guidance for when to use full, that would be great.
> 
> 
> I will start a thread on v6ops with some proposed txt "summarizing
> limitations and giving some guidance for when to use full" and see where
> we end up there before coming back at this.

OK. I'm planning on working on this next week, so if you can get some 
text then, that would be great.

> 
> 
> 
> 
>>>At a minimum, there should be a strong statement made in the draft
>>>that
>>>dual-stack hosts using 3484 SHOULD consider full implementation of
> 
>                                 ^^^^^^
> 
>>>ICE.
>>
>>I think that this is true in general, not just for dual stack. The
>>introduction, section 2.7, says this:
>>
>>It is important to note that the lite implementation was added to
>>    this specification to provide a stepping stone to full
>>    implementation.  Even for devices that are always connected to the
>>    public Internet, a full implementation is preferable if
> 
> achievable.
>                                                 ^^^^^^^^^^ 
> 
>>and later in the appendix:
>>
>>  It is important to note that the lite implementation was added to
>>    this specification to provide a stepping stone to full
>>    implementation.  Even for devices that are always connected to the
>>    public Internet, a full implementation is preferable if
> 
> achievable.
>                                                 ^^^^^^^^^^ ^^ ^^^^^^^^^^
> In both instances, I note the lack of requirements verb: at best, this
> will be interpreted as a lower case may. I was thinking RECOMMENDED or
> SHOULD.

OK, I am fine with SHOULD.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic