Re: Detailed review of Significance of IPv6 Interface Identifiers

I'd like to see Ray Hunter's proposed text added to the I-D, rather than being summarised. I find the detail quite useful. Honestly, it is a more clear justification/motivation for this significant specification change than anything else I've yet seen. So I believe that most other readers als

Re: u/g in general [was Mail from softwire working group about 4rd

On 12 Dec 2012, at 12:21 , Rémi Després wrote: > Do you know any deployment with u=g=1 in this context ? There is limited use today of IPv6 addresses that have apparent unicast routing prefixes, but contain multicast group IDs in the low-order 64-bits ("IID"). Yours, Ran ---

Re: u/g in general [was Mail from softwire working group about 4rd

On Weds 12th December, Remi Despres wrote, in part: > Not sure however that the two proposed questions > are clear enough because today: > - some IIDs have u = 0, and some have u = 1, > - some IIDs have g = 0, and some have g = 1. > The only combination that isn't used is u=g=1. While U==G==1 i

Re: Flow label drafts updated

Earlier, Brian Carpenter wrote: > I suggest squaring this circle by retaining the MUST NOT (which IMHO > is the present consensus) but making it clear in the security > considerations that there will be exceptions. The problem here is that > the RFC 2119 language doesn't provide MUST NOT UNLESS...,

Re: draft-gont-6man-managing-privacy-extensions-00.txt

On 10 Mar 2011, at 02:34 , Dan Wing wrote: > Nobody wants it removed in corporate deployments, either. That statement is far too strong; it simply is not true. > Consider for a moment an IPv6-enabled telephone, > on the desk of a Very Important Person at a company, ... (Laugh. I don't belie

draft-gont-6man-managing-privacy-extensions-00.txt

I recommend that folks read the above draft. I haven't seen the I-D announcement get cross-posted to the IPv6 WG, perhaps due to the volume of recent I-D postings, and the topic seems relevant. Cheers ! -

Re: Hop-by-Hop Extension Header processed in Slow Path?

On Friday 4th February 2011, at 06:39:51 +0530, Hing-Kam Lam wrote: > The below white paper from Cisco asserts that most vendors including > Cisco process Hop-by-Hop extension headers in CPU (slow path). > Is this correct? In general, it is not wise to trust any vendor X when they are talking abo