Ok. I assume this should be for FT? Or just something to get started?
Steve
-Original Message-
From: rfc-edi...@rfc-editor.org [rfc-edi...@rfc-editor.org]
Received: Tuesday, 13 Aug 2013, 18:18
To: ietf-annou...@ietf.org [ietf-annou...@ietf.org]; rfc-d...@rfc-editor.org
[rfc-d...@rfc-edito
Fernando,
Thanks for the careful review. Most of your comments lead to fairly obvious
fixes, which we'll apply in the next version. Just a few points below which
may need discussion:
On 14/08/2013 09:28, Fernando Gont wrote:
...
> * Section 1:
>> Unfortunately, experience has showed that as a res
Or more specifically,
OLD>
Extension Header:
Extension Headers are defined in Section 4 of [RFC2460].
Currently, six extension header types are defined. [RFC2460]
defines the Hop-by-Hop, Routing, Fragment and Destination Options
extension header types. [RFC4302] defines the Authentication
Hea
A new Request for Comments is now available in online RFC libraries.
RFC 6980
Title: Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery
Author: F. Gont
Status: Standards Track
Stream: IET
ack
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Tuesday, August 13, 2013 5:09 PM
> To: Ronald Bonica
> Cc: ipv6@ietf.org
> Subject: Re: I-D Action: draft-ietf-6man-oversized-header-chain-04.txt
>
> On 14/08/2013 09:01, Ronald Bonica wrote:
>
On 08/13/2013 06:01 PM, Ronald Bonica wrote:
> Brian,
>
> Good point. I will add MIPv6, Shim6 and 2 for experimental use in the next
> version.
>
> But is "No Next Header" really a header? For the purposes of this document, I
> don't think that it is.
Why not just avoid counting, note that som
Folks,
I've volunteered to provide a detailed review of this document, in
response to the 6man wg chairs' request.
Overall, I believe that this is a very useful document, and I support
its publication as an RFC.
However, I think it would be great if the technical comments below could
be addresse
On 14/08/2013 09:01, Ronald Bonica wrote:
> Brian,
>
> Good point. I will add MIPv6, Shim6 and 2 for experimental use in the next
> version.
And HIP.
> But is "No Next Header" really a header? For the purposes of this document, I
> don't think that it is.
I agree (and that is why I took it ou
Brian,
Good point. I will add MIPv6, Shim6 and 2 for experimental use in the next
version.
But is "No Next Header" really a header? For the purposes of this document, I
don't think that it is.
Ron
> -Original Message-
> From: ipv6-boun.
> Currently, six extension header types are defined. [RFC2460]
Not true. Please see Section 4 of draft-ietf-6man-ext-transmit
for a complete list including references. I make it eleven, if you
include experimental values, without counting "No Next Header".
Regards
Brian
> Long Title: "Stateless Automatic IPv6 Address Configuration (SLAAC) with
> Stable and Semantically Opaque Interface Identifiers"
>
> Short Title: "SLAAC with Stable and Opaque IIDs"
>
> I propose to use the word "opaque" here because the pseudo-random number
> generator is an implementation de
All,
This message starts the second two week 6MAN Working Group on advancing:
Title : Implications of Oversized IPv6 Header Chains
Author(s): F. Gont, V. Manral, R. Bonica
Filename: draft-ietf-6man-oversized-header-chain-04
Pages: 13
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : Implications of Oversized IPv6 Header Chains
Author(s) : Fernando Gont
Vi
Hi Hosnieh,
On 8/13/13, Hosnieh Rafiee wrote:
> Hi Andrew,
>
> Thanks for your comments. See my response as follow:
>
>> "prudent" and "best" are things that will change overtime. I can see the
> value in
>> publishing some algorithm to generate IID, and maybe the more of these we
>> have - the b
Follow up:
Just a mistake... not 32 bits... 32 bytes! Everything in my last email is
bytes and not bits... :-) I just got confused...
>
> Hi Andrew,
>
> Thanks for your comments. See my response as follow:
>
> > "prudent" and "best" are things that will change overtime. I can see
> > the
> val
Hi Andrew,
Thanks for your comments. See my response as follow:
> "prudent" and "best" are things that will change overtime. I can see the
value in
> publishing some algorithm to generate IID, and maybe the more of these we
> have - the better.
>
That section is related to the use of word "might
- Original Message -
From: "Brian E Carpenter"
To: "Dave Thaler"
Cc: "Fernando Gont" ; <6...@ietf.org>
Sent: Saturday, August 10, 2013 12:41 AM
> On 10/08/2013 11:01, Dave Thaler wrote:
> > I will observe that Alissa's term "random per-network" isn't in any
of the possibilities
> > below
"One of the
issues with this RFC concerns the wording that is used that allows
the implementation to make the choice as to what approach to use, and
in so doing, in some cases, the choice made is not the most prudent
or best approach, and this thus is not ideal and can lead to some
p
> For the record, this document doesn't address my feedback.
>
> Most of the I-D is about how to generate a random number.
>
> If you need a PRNG, just require implementations to implement one. Your
> workaround is to get into the same level of complexity to produce a PRNG
that
> wil be employed
19 matches
Mail list logo
