A new Request for Comments is now available in online RFC libraries.
RFC 3879
Title: Deprecating Site Local Addresses
Author(s): C. Huitema, B. Carpenter
Status: Standards Track
Date: September 2004
Mailbox:[EMAIL PROTECTED], [
Manfredi, Albert E wrote:
Perhaps the reason given in RFC 2402bis should be simply stated. The flow label described in AH v1 was mutable, and in RFC 2460 was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AH v2.
Sounds goo
Hi! I will appreciate if somebody can help me the following questions:
Q1:The description associated with "ipv4InterfaceIfIndex" implies
that it is same as the IF-MIB table's ifIndex of the _lower
layer_" interface on which IPv4 is being configured. Is this
inter
> Note that
> the current text MUST be changed, as it gives the wrong reason for
> not including the flow label under the ICV. So, we either change the
> rationale provided, or we change how we handle the field. All I was
> asking was which of these would folks prefer.
>
> Steve
Perhaps the r
At 12:39 PM +0300 9/13/04, Jari Arkko wrote:
Steve,
We are not talking about changing AH v1; we are discussing AH v2.
To correctly implement AH v2, one already has to be able to
accommodate 64 bit sequence numbers, vs. the 32 bit sequence
numbers in v1. AH v2 is still an I-D, not an RFC. So, whi
At 5:02 PM -0700 9/10/04, [EMAIL PROTECTED] wrote:
>Why do you think this is important and what problem does it solve?
This appears to be the key. Maybe I am missing something, but aren't
flow labels possibly looked at and used at hops in between the src
and dst? If the flow label is changed/hac
Soliman, Hesham wrote:
Having read the whole thread, I can't see any convincing reason
to include the flow label in AH.
=> I guess I've said my 2 cents on this point.
Apart from the arguments already expressed, what do we do if
AH fails because of a changed flow label? We discard the packet
inste
