Hi Konrad,
Thanks for your comments, see in line. These are my comments;
Sheng may want to comment too.
On 2010-06-08 23:30, Konrad Rosenbaum wrote:
> Hi,
>
> On Mon, June 7, 2010 09:41, Brian E Carpenter wrote:
>> This is another approach to stateless tunnels across subscriber NATs.
>
> There is of course the big question of how to discover a SAMPLE server. I
> doubt they would get any use if the user needed to enter anything in
> his/her configuration.
Well, that depends on the customer, but in general I think it needs to be
a one-click operation. At the moment we say
"The SAMPLE interface in the host MUST be configured with the IPv4
address and UDP listener port number of the SAMPLE server."
There are various ways of automating that, so maybe we can defer the
discussion until we know whether the method is useful.
>
> Anycast: runs the risk of landing you in the network of the wrong provider.
Absolutely; that would recreate some of the pain of 6to4.
>
> Guessing: ...usually goes wrong.
>
> Multicast: not supported by many/most CPEs.
>
> DNS based: kinda like Anycast... no matter how much magic you add.
Yeah, don't really want any .local nonsense.
>
> Maybe a centralized registry?
Or SLP. Or an IPv4 DHCP option.
>
>
>
> Also I would change the address format:
>
> 0 64 80 96 112
> +-------------+-------------+-------+------+------+------+
> | PSAMPLE | V4ADDR | PN |FILL |
> +-------------+-------------+-------+------+------+------+
>
> This way the host can set a /96 route to take a shortcut to any other
> SAMPLE host inside its own network instead of sending the traffic via its
> ISP. But it should be mentioned that under no circumstances host are
> allowed to shortcut to hosts with a similar prefix shorter than /96 - they
> cannot assume a compatible NAT.
Well, the draft uses as closely as possible the Teredo format. Also
we need to respect the u/g bit, which in your proposal means stuffing
2 bits into the V4ADDR field (more comments below). I'm not sure this
is worthwhile to avoid hairpinning.
>
> Also it would help to establish the exact handshake to arrive at the
> host-ID. My guess would be:
>
> Client(C), Server(S)
>
> C->S Router Solicitation with unspecified source, all-routers (ff02::2)
> destination
>
> S->C Router Advertisement with fe80::1 source, final host address
> (PSAMPLE:0000:V4ADDR:PN) as destination, PSAMPLE/64 as prefix, should be
> M=1?
>
> Now the host can set its host ID, randomize FILL and can do the handshake
> again if it thinks it is necessary.
>
> Whether the host-ID of the router should be ::1 or derived from an
> existing MAC is also debatable.
I think we can learn from Teredo experience on these things.
>
> Also I do not believe that V4ADDR and PN should be obfuscated - it does
> not solve any problem (attackers can simply reverse it) and introduces a
> few (the address is not easy to spot for support staff and it risks
> miscalculation by some implementers).
I personally agree. I'm not convinced that simple obfuscation of this
kind has any real value.
>
> Question: does it really make sense to set bits 6/7 of the host-ID to 0? I
> do not see much sense in serving the blind assumption of MAC-like behavior
> on a MAC-less interface.
That's a bit of a religious debate. Whenever it comes up, I suggest that
it's an issue for the 6MAN WG. Maybe you want to write a draft "U/G bits
considered harmful" or something.
> If so: is it safe to assume that no ISP will have
> an IPv4 prefix shorter than /8?
If nobody has one today, I think that's a pretty safe assumption.
Regards
Brian
>
>
> Konrad
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
