Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

Two points to clarify.. On Wed, 29 Oct 2003 [EMAIL PROTECTED] wrote: IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in dual-stack deployments where IPv6 connectivity is not yet enabled. could you clarify what you meant by dual-stack deployment? [...] if

Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

On Wed, 29 Oct 2003 [EMAIL PROTECTED] wrote: [...] Remember, the most important thing we should care about is that dual-stack deployments can get more common without causing problems for *IPv4* or services in general. AI_ADDRCONFIG is one step in that direction. for your story to be

Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and way too difficult to specify (for instance, if you have IPv6 global unicast address and no route, is it configured?). also, even without AI_ADDRCONFIG programs work just fine (socket(2) or connect(2)

Re: MTU handling and 2461bis

Adding MTU negotiations to 2461bis is a non-starter IMHO. The purpose of 2461bis is to clarify issues in the existing 2461, not add new features. I agree. I don't see how brand new, complex features can be added to the specification without requiring it to recycle to proposed. You

RE: Review: draft-ietf-v6ops-onlinkassumption-00.txt

This entire spec is predicated on statement in 2461 that are conceptual and not required as compliance to ND RFC 2461. Well, the behavior is actually used in section 6.3.6 Default Router Selection where section 6 is host specificatio, thus it isn't only a conceptual thing. 6.3.6

Re: Issue 3: on link assumption considered harmful

Hello, please read at the bottom: On Wednesday 29 October 2003 05:52, Jun-ichiro itojun Hagino wrote: This is a fairly straight forward issue. see: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00. txt 2461 says in section 5.2 : Next-hop determination

Re: RFC 2460 issue

Hi Fred, I agree that an ICMPv6 message should be sent by the router but I think it should be the Time Exceeded message (RFC 2463, section 3.3) rather than a parameter problem (section 3.4) message. Regards Suresh On Tue, 28 Oct 2003, Fred Templin wrote: Don't know about the sending host,

Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

On Wednesday 29 October 2003 08:26, Pekka Savola wrote: On Wed, 29 Oct 2003 [EMAIL PROTECTED] wrote: [...] Remember, the most important thing we should care about is that dual-stack deployments can get more common without causing problems for *IPv4* or services in general.

RE : RFC 2460 issue

Hi, The RFC 2460 says: Hop Limit8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. IMHO, this means: when the Hop Limit=0 the

Re: Issue 3: on link assumption considered harmful

On Wednesday 29 October 2003 14:49, Soliman Hesham wrote: I think this scenario is useful for IPv6 small-devices, so I don't quite agree with you all. I feel that we are undoing a lot of things and we will end up with no autoconfiguration features at all. This might be a good

Re: IPv6 w.g. Last Call on Unique Local IPv6 Unicast Addresses

Iljitsch van Beijnum wrote: On 24 okt 2003, at 18:14, Hans Kruse wrote: 2. Several folks stumbled over the wording (in section 1.0) that applications may treat these address[sic] like global scoped addresses. How about: Applications may treat these addresses like global scoped

Re: I-D ACTION:draft-main-ipaddr-text-rep-01.txt

Formally, no, this could be processed as an independent submission. But I think review by this WG is desirable anyway. Could the chairs give it 5 minutes on the agenda? Having written the original faulty ABNF, I feel some responsibility here... Brian Zefram wrote: [EMAIL PROTECTED] wrote:

Re: I-D ACTION:draft-ietf-ipv6-flow-label-08.txt

Matt, we went backwards and forwards many times on these timeouts in earlier versions. I agree with what you say as a common sense implementation heuristic, but I don't see how to cover it algorithmically in the spec. Since we are now at the stage of having resolved the IESG comments, do you

RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?]

Tony, Michel Py wrote: Note that p2p is not that unfriendly as of now. I just had a look at one of the pieces of p2p I use at home; there are some ^^^ 230k users on the server I connect to, ^^ Tony Hain wrote: And the inconsistency

Re: IPv6 w.g. Last Call on Unique Local IPv6 Unicast Addresses

I think that this effort is not ready for prime time. This document is creating a explosive cocktail made of: - policy: creation of a new authority to perform address assignment outside of the regular channels - economy: imposition of a fixed one time fee model, preventing competition

RE: RFC 2460 issue

I believe same as Savela here. Pretty obvious to me. /jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markku Savela Sent: Tuesday, October 28, 2003 3:21 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];