Le 20/10/2012 22:08, Mikael Abrahamsson a écrit :
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:
But with vehicles, one connects a vehicle here and gets a prefix,
then moves in that area and gets another prefix. At that point, if
the router obtaining a prefix wants to delegate further to another
vehicle needs to change the delegated prefix.
This dynamic change between the received prefix and the delegated
prefix is not a matter of DHCP. It can be implemented by like
scripting which are independent of DHCP implementation. One has to
touch the conf files be it of DHCP or of ND.
I'm sorry. I don't follow your reasoning.
Could you please write some text with a clear use case where
DHCPv6-PD can't be used for what you want to do, thus justifying why
your proposal is needed? Please keep it at a protocol level, not
implementation level.
Writing this text is feasible.
Let me first try an explanation here. This topology is extracted from
the draft. Is this kind of explanation what would make sense?
+----------+
| INTERNET |
| ACCESS |
+-----+----+
|
|
E2 |
+-------------------------+ +-------------------------+
| | | | |
| | | | |
| +-----------+ | E1 E1 | +-----------+ |
| | MR-LV |------|---------------|------| MR-IV | |
| +-----------+ | | +-----------+ |
| I1 | | | I1 | |
| | | | | |
| --------+-------- | | --------+-------- |
| | | | | | | | | |
| LFN-1 LFN-2 ... LFN-x | | LFN-1 LFN-2 ... LFN-x |
| | | |
+-------------------------+ +-------------------------+
Leaf Vehicle Internet Vehicle
We need MR-LV to be a DHCP Client and acquire a prefix that is
topologically correct both at MR-IV and in the infrastructure, to avoid
risks of ingress filtering.
Using DHCP-PD for LV in this figure can be done in two ways: (1) MR-IV
is a Client+Server or (2) MR-IV is a Client+Relay. In first case it has
the drawback that it has to change the prefix it delegates as Server
each time it acquires a new prefix as Client. This functionality is not
part of DHCP. Besides, the management of different parts (Client and
Server) of DHCP software on same machine may be cumbersome if I can say
so. Add that at times, there may be a need of a third part of DHCP, a
Client which requests a prefix over a tunnel not over the real iface
(DHCP-PD for NEMO). This becomes complex DHCP on same machine.
For the second case - MR-IV is a Client and a Relay, we assume that the
Server is in the infrastructure and not on MR-IV. At that point,
whenever the MR-IV Client changes its IP address, the Relay running on
the MR-IV must inform the Server about its new IP address. Otherwise
the relationship between Relay and Server can't work. This is not part
of DHCP and doesnt exist as far as I can tell.
Finally, the connection between MR-LV and MR-IV is a link which does not
use global addresses - only link local addresses. MR-LV does not
require an IP address from anywhere. It only needs a prefix for its
LFNs. The DHCP it may use to acquire that prefix is only a DHCP for a
prefix, not for addresses. At that point we may end up with a
requirement that _both_ DHCP _and_ ND to run on MR-LV.
But MR-LV may prefer to just run one protocol, not two. Because small.
If MR-LV must choose between which to run - ND or DHCP? It will choose
ND because it's the only one to give a default route. But ND doesn't
give it Prefix Delegation. Hence enhance ND with PD.
What is cleaner is to use existing standards where there already
is running code.
Right, there is cleanliness in reuse. Reuse as much as possible.
Then why do you feel the need to create something new when there
already is existing standards that will achieve the same thing?
For several reasons as expressed above. IT would be good to have only
one protocol to achieve this V2V2I but as it stands today it requires
two: ND and DHCP. Second, DHCP has some issues described according to
logic above.
In addition to FOSS (what is FOSS?) DHCP one also needs to
dynamically change the delegated prefix when the assigned prefix
changed.
FOSS = Free and Open Source Software.
WEll yes, I agree that IPv6 should be kept stable and part of that
may be that we try to make sure that a new proposal does not break
existing implementation. This is a matter of further work.
I'd say it's an absolute requirement that any proposal do not break
existing implementations.
Yes, noted and set aside to always consider it in further design.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
