Hello Michael,
Thank you for the reply. I have some comments, see below.
Le 28/11/2012 15:28, Michael Richardson a écrit :
"Alexandru" == Alexandru Petrescu
<alexandru.petre...@gmail.com> writes:
1) what use cases need topologically significant prefixes with
default routes
Alexandru> A vehicle assigned with globally-scoped IP subnet, and
connecting to the Alexandru> cellular network must be topologically
correct at the point of Alexandru> attachment, otherwise ingress
filtering prevents its communications to CN.
You explained the question in detail. All of what you wrote is
true, but it's also true that the Mars Curiosity Rover could share
it's bandwidth with Marvin Martian, but we are not yet planning for
that problem. This is the internet *ENGINEERING* task force, and we
have to make tradeoffs to solve problems people actually have, not
theorectical problems that might show up.
You didn't give me a use case.
A use case would be something like: SNCF wifi services needs this
when parked in an underground station where 3G will be unavailable
This use case implicitly tells me that the leaf vehicles are under
the same administrative authority, and share some kind of trust
relationship, and the uplink provider understands that multiple
prefixes will be required.
Let me explain.
I agree to usefulness of such usecase description - it expresses
incentive to immediate deployment and thus precise problems to be solved.
There may exist restraints to mention company names like 'SNCF' in
public emails. I am not employed by 'SNCF' and even if I sometimes work
_with_ e.g. 'SNCF' they wouldn't appreciate to see their most immediate
deployment plans revealed in public email lists. Hence this apparent
schism between my scenario description and real deployments.
That said, we do co-author a published I-D 'Scenarios Reqs' together
with an industry partner in this space and we are interested to
improving it, by getting comments of the kind you provided above - thank
you.
(draft-petrescu-its-scenarios-reqs-01)
2) what use cases need to exchange routes to locally configured
Non-Connected Network prefixes (whether RIR NCN, or ULA)
What is NCN non-connected networks - is there a reference, I am not
feeling lucky, thank you.
Alexandru> There are a number of specific vehicular communications
use cases which Alexandru> need one vehicle to communicate to
another even though the Alexandru> infrastructure is not available.
Alexandru> I mention one just for example but there are many others.
Alexandru> 'Platooning' involves a chain of one 'head' larger
{details deleted}
...
Alexandru> Other more entertainment 'V2V' communications involve
video conferencing Alexandru> between passengers of vehicles, and
more.
those seem like very useful things. Do you agree that they need
routing, not prefix allocation?
Yes and no.
There are two different cases: either each vehicle has hardcoded
prefixes or it has no hardcoded prefixes.
In the first case, if a vehicle has hardcoded prefixes - then routing is
needed, in your terms - the vehicle needs to inform the other vehicles
about its own prefix.
In the second case, if a vehicle has no hardcoded prefixes, then a
vehicle must obtain a prefix from somewhere, for its own use. If
infrastructure is not available, then it should obtain such a prefix
from a vehicle nearby.
Alexandru> Yes, I agree.
(1b) seems really easy in today's multiply NAT'ed IPv4, because
the NAT erases all evidence that first individual might have
violated an AUP. (I disagree with those AUPs)
Alexandru> Well ok and it seems impossible with non-NAT IPv6.
What I predict is that individuals that wish to share their uplink
connectivity, and are on providers which will not give them enough
prefixes so that they can share, will make use of either mobile IP or
other IP6-in-IP6 (including Teredo and ayyaya/aiccu) technologies to
get the addressing they need. I don't see a reason to need any
protocol other than DHCPv6 PD for this.
Ok, administratively, in the case _individuals_ need to share their
uplink connectivity. In addition to individuals, we also consider
groups of individuals (like train coach/wagon, or larger vehicles). For
these, the billing notion of 'individual' is blurred - it's more
'enterprise' or so.
An operator may wish initially to control this form of sharing either by
higher subscription rates($) for enterprise-class or by owning the
device (the Mobile Router). But as time advances, only the first is
kept in place - i.e. allow the SIM to be put in a non operator-owned
Mobile Router, but still charge more if traffic levels indicate some
form of sharing.
Technically, about Mobile IP, IPv6-in-IPv6 and DHCPv6-PD.
Mobile IP may indeed be used on one vehicle which has cellular
connectivity, SIM card. This has certain advantages. It may keep a
pre-allocated/hardcoded prefix in the vehicle and use tunnels to respect
topological correctness at the Internet in the fixed infrastructure.
But Mobile IP also has inconvenients. A vehicle without long range
connectivity (w/o SIM) but with short range like 802.11p/b, connecting
to another vehicle and using Mobile IP will involve artificially long
paths - not only classical triangular routing but rectangular routing (a
known problem in Mobile IP NEMO - 2 MRs, 2 HAs, 4 angles). This 4-leg
routing is so artificial when knowing that the two vehicles are just
there, one near the other. It's because Mobile IP.
Second, Mobile IP has one option of dynamically configuring the prefix
within the moving network - it's DHCPv6-PD for NEMO. This requires the
use of Relay and Client simultaneously on the MR. If that same vehicle
which does Mobile IP/NEMO also would be DHCP Server then one ends up
with a Relay, a Client and a Server on the same machine. Moreover, if
one needs that MR to sometimes obtain a prefix from the immediate
infrastructure (not from HA) then one ends with 2 Clients, Relay,
Server, all on same machine.
Other forms of dynamic IPv6-in-IPv6 tunnelling may indeed be considered
instead of Mobile IP. But conceptually they all suffer from same
problem - they need the presence of an infrastructure tunnel endpoint;
this is artificial when knowing the two vehicles are just there nearby.
I think that much of the challenge you have seen has been as a
result of trying to hack software that isn't architected to do v6-PD
client and server.
Well, I don't think DHCP-PD is architected to run 2 Clients, a Relay and
a Server on the same machine in order to achieve LV-to-IV
communications. There must be a simpler architecture to realize that.
And yes, we do consider ND to realize PD thinking it should be simpler.
dnsmasq has grown v6-PD recently.
Ok, I didn't know dnsmasq could do Prefix Delegation too.
In separate searches we identified other protocols that may-if-extended
do Prefix Delegation: EAP(PANA?), OSPF, LDAP.
We could discuss separately about each one of those.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
