Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]

[marcelo bagnulo braun <[e-mail]>]

El 07/03/2006, a las 2:11, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
>> I agree that we should care about robustness
>> But my point is that if someone is doing shim and it is using non 
>> routable ids, then he probably cares about robustness and so he 
>> should know that he must properly populate the reverse DNS.
>
> They might think they have populated it correctly, but if it "never"
> gets used there is no easy way for them to tell.
>
> I think some careful judgment is needed here, so ensure that it isn't 
> only during failures in combination with other events (such as 
> referrals or long-lived application sessions), that the ID->locators 
> would be looked up in the DNS.
>
> Taking a car analogy. Folks are reasonably confident that the breaks 
> on the car works, because they use them when slowing down, and when 
> stopping at intersections.
> If the breaks where only used for emergencies (such as somebody 
> jumping into the street just in front of you, or the car in front 
> suddenly slamming its breaks), then it would be too late to discover 
> you were out of break fluid.
>

right, but you probably don't want to periodically crash into things to 
verify the airbag... ;-)

I can see your point and i agree that this needs to be taken into 
account.

Perhaps an option could be to get the identifiers and the locator from 
the direct DNS when the fqdn is resolved AND also perform the reverse 
mapping from the ID to the locator set, to verify that the information 
is there.
So, when the fqdn is resolved, the host has all the information and can 
proceed with the communication establishment. But also, if after 
performing the reverse lookup it discovers that it is not properly 
populated, some kind of error message can be returned, so that the 
admin of the zone is informed.
In this way, you can periodically verify the reverse zone, but reduce 
the cost involved in the verification operation. I mean there are two 
costs involved in the verification: the packet overhead due to the 
query and the added latency of waiting to obtain the locator 
information. IMHO the second one is the most problematic. With this 
option we would be eliminating the second one and just keeping the 
first one.


>
>>> We can encode the address type in different ways. One way would be 
>>> to use a flag field in the verification method. Another would be to 
>>> use the IPv4-mapped address format (::ffff:1.2.3.4). Both would work 
>>> AFAIK.
>>>
>> sure
>> but i guess that my point is that if already identify that we may 
>> need additional flags about the address information, it would be a 
>> good option to redefine the verification method to a generic flag 
>> octet, in order to support future flexibility (this is somehow 
>> independent of the option selected for the v4 address, is more a 
>> general observation)
>
> Yes, but if we want to support different types of locators (IPv6, 
> IPv4, and perhaps IPv4+UDP port for NAT traversal), then maybe we 
> should have an explicit locator type? (and length?)
>

well, i guess that we don't need more than 128 bits, so probably if the 
locator field is 128 bits, this would be enough.
w.r.t. to the explicit locator type, perhaps the option would be to use 
3 bits of the flag field to express this...
> ...

>> wouldn't the Sent locator option and the received locator option be 
>> useful for dealing with NATs?
>> I mean using these, a host can find out if the addresses were 
>> rewritten (whether by a router or a nat doesn't matter i guess), and 
>> discover its own addresses and eventually add them to the Ls
>
> Yes, that is potentially useful. Hadn't thought about that (I try to 
> avoid spending precious brain cycles on inventing yet another NAT 
> traversal mechanism).

> But the semantics might be different.
> With a NAT rewrite it presumably means that some other address (the 
> one in the source in the Sent locator option) is no longer useful.
> But with router rewriting, that address might still be useful but just 
> isn't recommended (e.g., due to TE) for this communication.
>

agree but i guess that it is easy to determine that in the NAT case (in 
the general case). I mean, if the other end sees a public address and 
we are using a private address, then the private address is unreachable 
from the peer and must be substituted with the public one received in 
the option.

If both v4 addresses received are public, then this is TE and both are 
ok.

(The problem is that now some very big sites are starting to use public 
addresses when they run out of private addresses 
(http://www.arin.net/policy/proposals/2004_3.html) which would break 
the simplicity of the approach. But even in this case, the local host 
should be able to know which are the addresses reserved for private use 
and apply the same heuristic mentioned above


>> In addition, as you mention in the draft the failure detection 
>> mechanism could be used to preserve the NAT state if detected.
>
> Detection and preservation are different things.
> To preserve one would have to determine how often the NAT needs to see 
> packets in order for it to not discard the state. This is hard. Or one 
> has to send a packet every N seconds all the time, which generates 
> lots of extra load.
>

yes, but shim is supposed to be able to deal with failures and the NAT 
loosing its state can be seen as a failure. So, the shim will be able 
to recover from this and even recreate the NAT state. Probably we need 
some additional logic to be smart enough to identify that what is going 
on is that the nat is loosing state and increase the keepalive 
frequency.
I mean, in the case of the shim, the communication can be recovered 
from a nat loosing state and the state in the nat can be easily 
recovered.

>> Probably the piece that is missing is somehow of rendez vous server 
>> for initial contact for hosts behind nat
>
> Which is hard.
>
> One can observe some similarities between a NAT rendez-vous server, 
> and a mobility home agent, in that they both could be a (set of) fixed 
> locators where one can send packets (and have them be forwarded on, 
> and later route optimized away), with a mechanism for the host to keep 
> the rendez-vous server updated with the current locators of the host.
>
> But this is harder for NAT than for IP mobility; with full cone NATs 
> it could be a single IPv4 address plus port as the locator. But with 
> stricter NATs then each peer has to find a different IP+port to talk 
> via the NAT.
>

yes this is a completely new piece that is missing and i guess that in 
this case, it would make sense to try to import any solution designed 
somewhere else to deal with this problem

> All good reasons for me to focus on
>  - completing the ID/loc split,
>  - TE feedback
>

i agree with the approach, just wanted to explore this a bit

> and let somebody else think about NAT traversal.
>
>
>> I guess that locator selection incorporates several elements:
>> - Rechability
>> - Preferences with respect the different types of locators (CoA vs. 
>> HoA, scope, private etc)
>> - TE/policing issues (including local preferences and remote 
>> preferences (the preferences of the peer))
>> RFC3484 can be used to express the tree items somehow (with its 
>> limitations) (note that it does not help to determine if an address 
>> is reachable or not, but it does take this information into account 
>> when performing dest address selection)
>> In addition, the locator selection is performed:
>> - when the communication is initiated (whether when a routable id is 
>> selected (just RFC3484) or when a non routable id is used and the 
>> shim selects a correspondent locator)
>> - when a failure occurs,
>> - because of TE considerations, a host may choose to change the 
>> locator
>> I would say that in any of those cases, it is importnat to take into 
>> account all the aforementioned 3 items, so i guess that RFC3484 may 
>> be a good candidate for locator selection
>
> s/good candidate for/provides some additional constraints on/
>
>> But not only availability must be taken into account for exploring 
>> and rehoming i guess.
>> First of all, you probably want to take into account considerations 
>> like scope, HoA vs. CoA, private vs. public addresses when selecting 
>> which address to explore
>
> Sure. But the tradeoffs are quite different in a shim6 locator 
> selection
> context that in address selection.
>
> For instance, for private vs. public in order to provide pseudonymity 
> the host has to keep multiple sets of <temporary ULID, set of 
> temporary locators> and never combine ULID/locators across the sets, 
> since that would provide a linkage over time where the host can be 
> tracked even though it changes its ULIDs and locators over time.
>
> For HoA/CoA the tradeoffs are different when used as address today 
> (where using a CoA can easily cause communication to fail), and using 
> it as a locator with shim6.
>
> So RFC 3484 does help to list some things to consider, but doesn't 
> provide useful answers for the issues with shim6.
>

i agree with the points made above

So what we need is a locator selection algorithm that is likely to take 
into account the same issues that RFC3484 does, but with different 
trade-offs being made, right?


>
>>> One of the interesting things is the combination of the unroutable 
>>> ULID and getting router feedback during the context establishment 
>>> exchange (which will be done before any ULP packets are exchanged in 
>>> that case).
>>> If we only allow rewriting on packets with the payload extension 
>>> header we wouldn't have that capability of early locator selection 
>>> according to the policy implicit in the router's rewriting.
>>>
>> but how early is this compared to the case where no rewriting is 
>> supported for control packets?
>> I mean, in the case of no rewriting for control packets, the first 
>> payload packet would get rewritten and the capability would only get 
>> delayed for 2 packets i.e. the shim context establishment packets, 
>> which i don't think is an issue...
>> but probably i am missing the point you are making...
>
> My point is that if we have unroutable ULIDs, then there isn't any 
> extra cost I can see for allowing the rewrite of on the I1/R1 etc 
> messages; those messages get a bit larger that's all.
>
> Without rewriting in I1/R1/etc we get rewriting for the first data 
> packet resulting in an Update Request message to inform the sender of 
> a rewrite, potentially followed by an Update Request in the reverse 
> direction to inform the peer that it can use that new locator as a 
> destination.
>
>
> And if we are pursuing router rewriting, a simple test for "can this 
> packet be rewritten" might be important for performance. With 
> rewriting on shim6 control packets, this test is
> 	if (ip6->ip6_nxthdr == IPPPROTO_SHIM6)
>


i may agree with that.
It is just that i am concerned about the added complexity to the 
protocol itself, which is already quite complex...

regards, marcelo



>
>    Erik
>