On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote: > >>>>>> "Yaron" == Yaron Sheffer <yaronf.i...@gmail.com> writes: > Yaron> I don't want to speak for MCR, but I think you are taking his > Yaron> question too far towards the implementation aspects. What I > Yaron> read in the question is, do we allow for a situation where > Yaron> (by policy and/or because of limitations in the solution) an > Yaron> endpoint cannot connect directly to the ultimate peer, but > Yaron> needs instead to go through some sort of relay. > > You didn't take my comments too far; I think you realized that I was in > fact saying two things: > > 1) when traffic is redirected, MUST it be redirected directly to the > real endpoint? (There might be issues of in-band double NAT that > matter if the traffic doesn't get all the way there... I dunno, IPv6 > RFC6145 is my answer to double NAT) > > 2) when traffic is redirected, MAY it be redirected more than once?
Aren't these really the same question? My answer is that it's OK for redirection to happen more than once, but it's better to have less redirections than more. IOW it should be a requirement that H1 (in the diagram of your previous mail) be able to send more information about the topology behind H2 than just "B is behind H2", such as "D and H3 are also behind H2". But A should be required to not expect it. So H1 MUST be able to tell A that B is behind H2. It MAY be able to tell A that D is also behind H2, or that B is actually behind H3, or the actual address of B. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
