[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Comments on the DNA goals draft
Dear Jari
Thanks for your kind and helpful comments. Kindly find my in line
comments.
> > When a link-layer connection is established or re-established, the
> > host doesn't know whether its existing IP configuration is still
> > valid for Internet connectivity. A subnet change might have occurred
> > when the host changed its attachment point.
>
> Question: Is this true for all link layers? It was not true for
> PPPv4, for instance. It is true for PPPv6, but only for global
> addressing, not link-local communications. Is it true for 3GPP
> and 3GPP2 networks?
I discussed this with Jim and come to think that the following phrase
is more precise. The phrase use 'MAY NOT' instead of 'DOESN'T'.
When a link-layer connection is established or re-established, the
host MAY NOT know whether its existing IP configuration is still
valid for Internet connectivity.
> > Today a link change necessitates an IP configuration change.
>
> I think you mean "... necessitates an IP configuration be
> verified or re-ackquired", because you could certainly
> move from one link to another and have all your IP parameters
> stay the same. Or do I misunderstand the term "link"?
Yes, I think so. At least in the sense defined in the goals draft.
What I mean is "When a host moves to a new link, its
existing IP configuration is no longer valid."
We define link as of RFC 2461,
a communication facility or medium over which nodes can communicate
at the link layer.
Here is the example which will illustrate my point.
Suppose two APs are one the same ethernet segment and share one AR
like below. Also assume an MN is attached to an AR through AP1.
|
__|____
| |
| AR |
|___ __|
__________|__________________
| |
__|__ __ |__
| AP1 | | AP2 |
|____ | |___ _|
Though there are two BSS, there is only one link. If the MN moves from AP1
to AP2, it still remains at the same link.
Kindly find my presentation at 58th IETF meeting in which I tried to clarify
the notion of link there.
http://www.ctie.monash.edu.au/dna/DNAv6JH58.ppt
In the discussion concerning terms, L2 link and L3 link, we decided to use 'link'
for 'L3 link' and 'attachment point' for 'L2 link'. For more detail kindly find
my Jason (:-)) mails.
> > Even if an address prefix is valid, an individual address is known to
> > be valid only after the Duplicate Address Detection (DAD) procedure
> > [5] has been completed.
>
> Do you assume that the host knows an L2 change has occurred? If
> so, running DAD may be necessary. But if you don't reliably know
> that L2 change has occurred, you don't know when you should be
> rerunning your DAD.
I guess it's safer for a host to rerun DAD
NOT when it reliably knows that L2 change has occurred
BUT when it doesn't reliably know that L2 change has not occurred.
> On the other hand, if the same prefixes are still valid on
> this new link as were on the old L2, how come DAD needs to
> be rerun? From a global perspective, if there two L2 instances
> use the same IP prefix, a DAD performed on one link should
> be visible on the other too, otherwise we can have a
> collision.
I had in mind is the case that a host changes APs while staying on the same
link with huge L2 handoff delay, the period between deassociation with an
old AP and reassociation with a new AP. For example, Boeing people are using
4 satellites around the world to get 5Mbps downlink to the airplanes, and it
takes 30sec for the airplane to handover from one satellite to the other.
In such cases, I thought DAD is necessary even when a host is attached to
the same link after a L2 handoff. Because while a host is away from a link,
another host may happen to use that address.
> > On the other hand, a host can't be sure that its default router is
> > reachable, even if it can communicate with the router that has the
> > same address as its existing router address. That router may be a
> > different one, which happens to have the same link-local address as
>
> What do we assume about the reason why they have the same link-local
> address? I can imagine EUI-64 collision as one such reason. However,
> if that is the case, the what Bernard recommends for DNAv4 (checking
> IP and MAC addresses of the default router) would fail under similar
> conditions.
>
> It would be good to be more precise about what failure mode we
> are trying address. Is it the manual configuration of two routers
> to have the same link local address?
It would be more precise to express that "two different router
interfaces may have the same link-local address."
'
In case of a router has multiple interfaces, I was notified that
it's not uncommon to assign the same link-local address to
all those interfaces.
> > DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of
> > limited signaling. The solutions should correctly determine whether
> > a link change has occurred. They also should be sufficiently fast
> > lest there should be service disruption. They should not flood the
> > link with related signaling.
>
> You could write this shorter as
>
> DNA solutions should correctly determine whether a link change has
> occurred. They also should be sufficiently fast lest there should
> be service disruption. They should not flood the link with related
> signaling.
ok.
> > G2 When upper-layer protocol sessions are being supported, DNA
> > schemes should detect the identity of an attached link rapidly,
> > with minimal latency.
>
> I would think ULP sessions are supported in all nodes :-)
>
> I think you mean "... sessions are expected to survive link changes, ..."
yes. I think the following is more clear.
......DNA
schemes should detect the identity of an attached link rapidly,
with minimal latency lest there should be service disruption.
> Anyway, I'm not sure this alone is the one and only reason for having
> a rapid process. I also want my portable device to react fast when
> I press "On" or "Internet".
I agree that this isn't the one and only reason. But people are generally
more patient when they don't have on-going session. When they boot
the device, they will wait more, though not indefinitely.
> > G7 DNA schemes should be compatible with security schemes such as
> > Secure Neighbour Discovery [8] and IPSec [7].
>
> I understand the SEND part. Not sure I understand the IPsec
> part (note the small "s"). Do you mean that DNA should work
> when IPsec is being used to secure ND? Or when you use IPsec
> in general? I sure agree with the latter, but in that case
> it should probably say something TLS and bunch of other things
> too... perhaps you could clarify what your requirement is.
I see. We will clarify this.
> > Use of [8] to
> > secure Neighbor Discovery are important in achieving reliable
> > detection of network attachment.
>
> s/are/is/
Oops. Thanks.
> > Security Considerations
>
> You may want to add something like what Bernard wrote in
> his DNAv4 document about not trusting the DNA procedures
> to turn on/off your personal firewall based on "recognizing"
> your home network. At least if you are not using SEND.
ok.
Thanks for your kind consideration.
Best Regards
JinHyeock