Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

2005-04-13 Thread Joe Abley
On 13 Apr 2005, at 21:06, Rob Austein wrote: So the criteria here are: a) Short-lived session (typically two packet UDP exchange, but some argue that even a fast 7 packet TCP exchange is ok, so long as it's fast); For the record, I know of people who have distributed video streaming services

Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

2005-04-13 Thread Rob Austein
Upon further analysisI agree with Joe. I was trying to meet Bob halfway, but upon reflection have concluded that I was wrong to do so. Anycast is complicated, and the complications are not specific to IPv6. It really would be doing the world a favor if the IPv6 WG were to get rid of the lang

Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

2005-04-13 Thread Joe Abley
Hi Bob, On 13 Apr 2005, at 17:13, Bob Hinden wrote: Arbitrary use of Internet anycast addresses is not recommended. There are known complications and hazards when using them in their full generality [ANYCST]. Specific usage guidelines are: 1) Anycast may be used for simple query

Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

2005-04-13 Thread Rob Austein
At Wed, 13 Apr 2005 14:13:34 -0700, Bob Hinden wrote: > > Here is a proposal (rough) based loosely on Fred Baker's proposal and > subsequent discussion on the list: > > Arbitrary use of Internet anycast addresses is not recommended. There > are known complications and hazards when using

Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

2005-04-13 Thread Bob Hinden
Hi, [Document author hat on] Interesting discussion. Sorry for not responding to this thread, but I have been dealing with a family matter and wasn't staying current with email. I think there is general agreement that we can relax the anycast rules specified the address architecture. The relev

RE: Security considerations of the ICMPv6 draft

2005-04-13 Thread Mukesh . K . Gupta
Ok so we are pretty much decided on adding the awareness text. What about we add the following text to cover your second point also (i.e. recommending the upper layers to use the payload for validation). === 6. As the ICMP messages are passed to the upper-layer processes, it is possi

IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt

2005-04-13 Thread Brian Haberman
IPv6 WG, This is a status update on the centrally-allocated ULAs defined in draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it is prudent to gain operational experience with the locally-assigned ULA specification (which is currently in the RFC Editor's Queue) before contin

IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt

2005-04-13 Thread Brian Haberman
This starts a 2 week IPv6 WG Last Call for advancing: Title : Considerations on M and O Flags of IPv6 Router Advertisement Author(s) : S. Park, et al. Filename: draft-ietf-ipv6-ra-mo-flags-01.txt Pages : 13 Date: 2005-3-

RE: Security considerations of the ICMPv6 draft

2005-04-13 Thread Fernando Gont
At 13:57 11/04/2005 -0500, [EMAIL PROTECTED] wrote: I agree that we should add some words to raise awareness about the ICMP-based attacks. We could add the text that Pekka suggested in the security consideration section and provide an informative reference to your draft. That'd be a good thing. I