Re: site local addresses

>> Except of those 14 some seven(?) are RFC3041 addresses, which break a >> number of applications... so there are some clouds in the sky. > > 3041 may be next on the hit-list. Pretty soon it truly will be > nothing but bigger addresses. lets shoot down those 128 bit addresses too, 64 must be eno

Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

> Further to that, ifindexes of tunnels and PPP sessions can change dynamically > as the bearer connection goes up and down, even if the interface has the same > name and authenticated identity. That raises the interesting question of > whether even the interface name is stable, as on many syst

Re: Review of draft-gundavelli-v6ops-l2-unicast

Bernard, thanks for a very thorough review. [I didn't see this before the IESG raised a DISCUSS, it must be useful for the authors / wg to see these reviews too?] [...] > In the abstract, the draft correctly states that it is not mandatory that > the link layer destination of an IP multicast p

Re: Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

Keith, I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree. > I strongly object to the proposed reclassification of these documents as > Historic. > > 6to4 still has many valid use cases, and there is not a suita

Re: one data point regarding native IPv6 support

Michel, making 6to4 historic does not affect 6rd. I think the draft says that much too. I don't think we are saying that native necessarily is better than tunnels. we are saying unmanaged tunnels crossing the Internet is bad. 6rd is managed and contained within a single SP's network. cheers, Ole

Re: Gen-ART LC Review of draft-ietf-v6ops-6to4-to-historic-04

Ben, splendid comments! I've tried to incorporate all of them, and will either issue a new revision or make the changes during AUTH48 depending on other LC feedback. cheers, Ole > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at >

Re: one data point regarding native IPv6 support

Noel, >> it seems that a lot of the issues could be mitigated by simple >> connectivity test. > > Well, IPv6 Neighbour Discovery is just the thing. I gather it's turned off > on 6to4 links, which in retrospect was probably a mistake. I would > recommend that it be turned on, but apparently the WG

Re: draft-ietf-v6ops-6to4-to-historic

Roger, > Guess I should clearify something, the thing I am considering are to > drop all 2002::/16 addresses hard, of course preferable return a > correct error messages to. > > wonder how many find 6to4 usable when ISPs start doing that? Nuclear > winter or not may follow. took me a while to wa

Re: 6to4 to Experimental? (was: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic)

Keith, > The alternative that I proposed to IESG and to the chairs (and never received > any feedback about) was to reclassify 6to4 as Experimental. Experimental > seems completely appropriate for a protocol that is useful, but only in > corner cases. And I think it's also appropriate and us

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

I'm in favor of the proposed action and the clarification of historic, suggested in the new section. (I could be in _strong_ favour to nullify Keith's 'vote', although I hope we're not counting. ;-)), . cheers, Ole On Jul 25, 2011, at 10:30 , Ronald Bonica wrote: > Folks, > > After some discu

Re: IPv6 traffic distribution

Michel, >> Joel Jaeggli wrote: >> 6rd is global unicast... there's nothing to discriminate >> it from any other native range. > > No. there is nothing in the current classification algorithm to > discriminate from any other native range. But it's not native, as it > has, among other things, the s

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Fred, > Hi, I would like to make a small amendment to what I said in my > previous message as follows: > > 4) Section 5, change the final paragraph to: > > "As a result of the above mentioned requirements, a packet's header > chain length MUST fit within the Path MTU associated with its >

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Fred, >> -Original Message- >> From: Ronald Bonica [mailto:rbon...@juniper.net] >> Sent: Tuesday, October 08, 2013 5:46 PM >> To: Ole Troan; Templin, Fred L >> Cc: i...@ietf.org; ietf@ietf.org >> Subject: RE: Last Call: >> (Implications of

Re: Last Call: (Implications of Oversized IPv6 Header Chains) to Proposed Standard

Fred, >>>> -Original Message- >>>> From: Ronald Bonica [mailto:rbon...@juniper.net] >>>> Sent: Tuesday, October 08, 2013 5:46 PM >>>> To: Ole Troan; Templin, Fred L >>>> Cc: i...@ietf.org; ietf@ietf.org >>>> Subje