From: Iljitsch van Beijnum [EMAIL PROTECTED]
Date: 2006/09/14 Thu PM 02:26:39 CDT
To: [EMAIL PROTECTED]
Cc: IETF IPv6 Mailing List ipv6@ietf.org
Subject: Re: Endianness of IPv6 and payloads
On 13-sep-2006, at 20:15, Bob Hinden wrote:
In my personal view, while this is a nice theoretical
Good afternoon all. With all due deference and respect to my more senior IETF
colleagues (participating in this thread and in the group at large):
From: Pekka Savola [EMAIL PROTECTED]
Date: 2006/09/16 Sat PM 12:13:40 CDT
To: Eric Klein [EMAIL PROTECTED]
Cc: Thomas Narten [EMAIL PROTECTED],
Good morning all,
John makes an excellent point. I'd be happy to assist anyone writing the draft.
Best Regards,
Tim
Rom 8:28
From: [EMAIL PROTECTED]
Date: 2006/09/16 Sat PM 11:31:41 CDT
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: ipv6@ietf.org
Subject: RE: Endianness of IPv6 and payloads
.
Further, section 10.1 of that same spec provides what are IMO good examples
thereof.
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman
Hi Elwyn, thanks for the clarification. Responses in-line.
Tim Enos wrote:
From: Su Thunder [EMAIL PROTECTED]
Date: 2006/09/26 Tue AM 10:53:59 CDT
To: ipv6@ietf.org
Subject: A question about Source Address of IP Field of ND Packets(RFC2461)
The Source Address of Router
stray. I say 'reduce' as opposed to 'eliminate' as
in other cases I've seen implementations hard-code variable values where the
spec explicitly said they MUST be configurable.
Hesham
Best Regards,
Tim Enos
Rom 8:28
I do not see any benefit in having any
specification state *which
. (slides available upon
request.)
Interesting title. Would you please also send me a copy of the slides?
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1
space.
So, at this point, I do not support this draft.
- Alain.
Respectfully,
Tim Enos
Rom 8:28
-Original Message-
From: Brian Haberman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 02, 2007 12:41 PM
To: ipv6@ietf.org
Subject: WG Request: Adopt draft-haberman-ipv6-ra-flags
space.
So, at this point, I do not support this draft.
- Alain.
Best Regards,
Tim Enos
Rom 8:28
-Original Message-
From: Brian Haberman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 02, 2007 12:41 PM
To: ipv6@ietf.org
Subject: WG Request: Adopt draft-haberman-ipv6-ra-flags
they wrote a draft that required the use of (theretofore unused) IID
space. The one-stop shopping would be nice.
Best Regards,
Tim Enos
Rom 8:28
Thanks
Suresh
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
Yes, absolutely. Rob, I couldn't agree more.
From: Rob Austein [EMAIL PROTECTED]
Date: 2007/04/25 Wed AM 09:13:36 CDT
To: [EMAIL PROTECTED], ipv6@ietf.org, [EMAIL PROTECTED]
Subject: Re: IPv6 Type 0 Routing Header issues
At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote:
The
Hi Bob/all,
I advocate for option #1. IMO, the paper found by following the link below
makes a good case against the use of IPv6 Routing Header Type 0:
http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf.
The following I-D (perhaps among others) also succinctly delineates the
potential
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
,
Jeroen
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
,
Jeroen
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
).
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Best Regards,
Tim Enos
Rom 8:28
by RH0 is required, I'd support creation of a new
routing header (disabled by default). Just my two cents.
-Ryan
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
Hi Ryan,
Good point about including the whole sentence; mea culpa! :^\
On Wed, May 16, 2007 at 05:09:34PM -0500, Tim Enos wrote:
In section 4.2, IMO it would seem good to see a brief justification of
the statement: filtering based on the presence of any
Routing Headers on IPv6 routers
. What do I do?
__
Best Regards,
Tim Enos
Rom 8:28-39
This starts a two week IPv6 working group last call on advancing
Title : Deprecation of Type 0 Routing Headers in IPv6
Author(s) : J. Abley, et al.
Filename: draft-ietf-ipv6-deprecate-rh0-01
work is meant to be predicated upon group consensus
I'd say it should be removed from the charter.
Regards,
Brian
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
will not move the ULA work forward
if the current non-consensus situation does not change.
Thank you.
Brian Carpenter wrote:
6man, and tweak the charter to cover address architecture maintenance,
This would be my take too.
Jari
Tim Enos
Rom 8:28
controlled networks; to be of general use, a benign source routing
option would need a new codepoint.
Joe
Best Regards,
Tim Enos
Rom 8:28-39
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1
/707/cisco-sa-20070808-IOS-IPv6-leak.shtml
itojun
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
with current policies on peering LSRR, please let
me know.
a+
Best Regards,
Tim Enos
Rom 8:28
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
I too would be in favor of a SHOULD for the AH requirement, with language
dedicated both to a specific example of where AH is arguably a MUST (e.g. for
nodes implementing OSPFv3), and other language which at least outlines where AH
is and is not applicable.
Best regards,
Tim Enos
Ps 84:10-12
Mea culpa. I stand corrected on that particular point, and am glad FWIW that
RFC 4552 does in fact state:
In order to provide authentication to OSPFv3, implementations MUST
support ESP and MAY support AH.
Couldn't have written it better myself.
Best regards,
Tim Enos
Ps 84:10-12
Subject
27 matches
Mail list logo
