Hi Gabi,
I'm sorry to have to keep turning this into plaintext,
but annotation is difficult otherwise. See below for
my responses (==>):
From: Gabi Nakibly [mailto:gnaki...@yahoo.com]
Sent: Wednesday, August 19, 2009 1:49 AM
To: Templin, Fred L; v6ops
Cc:
Remi,
See my comments inline ().
Gabi
From: Rémi Després
To: Gabi Nakibly
Cc: v6ops ; 6man 6man ; sec...@ietf.org;
Mark Townsley
Sent: Tuesday, August 18, 2009 8:00:42 PM
Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case
I must admit that
On 11 aug 2009, at 16:09, Sam Hartman wrote:
We have not reached a consensus that LISP needs to work through NATs.
I'll take your message as a statement in favor of that and a personal
opinion that they need to.
Please put me down in the "that's insane" column.
Fred,
See my comments inline ().
From: "Templin, Fred L"
To: Gabi Nakibly ; v6ops
Cc: ipv6@ietf.org; sec...@ietf.org
Sent: Tuesday, August 18, 2009 6:48:45 PM
Subject: RE: Routing loop attacks using IPv6 tunnels
Now let me see that I understand Section 6.2 co
Remi,
Well, I also think that there should also be a proper check in the spec.
Notice, that there are valid cases in which looping a packet back to yourself
is OK. For example, if two processes on the same host communicate with each
other. However, I do think that an alert implementer of a Teredo
Hello, Fred,
> There are a number of RFCs with specific values. You might look at RFC
> 2473 (64), RFC 3122 (255), and RFC 3315 (32). Neighbor Discovery wants a
> hop limit of one.
(Side-tracked, but: think it wants 255, for GTSM)
>each of those specifies a specific case in which the
> value a
There are a number of RFCs with specific values. You might look at RFC
2473 (64), RFC 3122 (255), and RFC 3315 (32). Neighbor Discovery wants
a hop limit of one. each of those specifies a specific case in which
the value applies.
For IPv6 unicast traffic, I think it's fair to say "wider tha
