Re: vehicular communications, nd-pd, prefix exchange
Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 29 November 2012 12:30 UTC
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2C21F89B5 for <ipv6@ietfa.amsl.com>; Thu, 29 Nov 2012 04:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Level:
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx3OooZEOQU3 for <ipv6@ietfa.amsl.com>; Thu, 29 Nov 2012 04:30:21 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C207421F89F7 for <ipv6@ietf.org>; Thu, 29 Nov 2012 04:30:20 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qATCUJEe031009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Nov 2012 13:30:19 +0100
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qATCUIRM016187; Thu, 29 Nov 2012 13:30:19 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qATCU50U025226; Thu, 29 Nov 2012 13:30:18 +0100
Message-ID: <50B7554D.7040109@gmail.com>
Date: Thu, 29 Nov 2012 13:30:05 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: vehicular communications, nd-pd, prefix exchange
References: <5081087D.2020807@gmail.com> <509A5471.5000603@gmail.com> <13826.1352300160@sandelman.ca> <509AE892.1060907@gmail.com> <13792.1352398323@sandelman.ca> <50B5E480.2090702@gmail.com> <26379.1354112905@obiwan.sandelman.ca>
In-Reply-To: <26379.1354112905@obiwan.sandelman.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2012 12:30:22 -0000
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.petrescu@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 >
- Announcing Prefix Delegation extensions to ND dra… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Mikael Abrahamsson
- Re: Announcing Prefix Delegation extensions to ND… Philipp Kern
- Re: Announcing Prefix Delegation extensions to ND… Behcet Sarikaya
- Re: Announcing Prefix Delegation extensions to ND… Mikael Abrahamsson
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… sthaug
- Re: Announcing Prefix Delegation extensions to ND… Mikael Abrahamsson
- Re: Announcing Prefix Delegation extensions to ND… Mikael Abrahamsson
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Mikael Abrahamsson
- Re: Announcing Prefix Delegation extensions to ND… Doug Barton
- Re: Announcing Prefix Delegation extensions to ND… Hesham Soliman
- Re: Announcing Prefix Delegation extensions to ND… Thierry Ernst
- Re: Announcing Prefix Delegation extensions to ND… Mark Smith
- Re: Announcing Prefix Delegation extensions to ND… Karl Auer
- Re: Announcing Prefix Delegation extensions to ND… Mark Smith
- Re: Announcing Prefix Delegation extensions to ND… Mark Smith
- Re: Announcing Prefix Delegation extensions to ND… Karl Auer
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Brian E Carpenter
- Re: Announcing Prefix Delegation extensions to ND… Ralph Droms
- Re: Announcing Prefix Delegation extensions to ND… John Mann
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing...) Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- RE: Announcing Prefix Delegation extensions to ND… STARK, BARBARA H
- Re: Announcing Prefix Delegation extensions to ND… Michael Richardson
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing...) Michael Richardson
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing...) Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Alexandru Petrescu
- Re: Announcing Prefix Delegation extensions to ND… Thierry Ernst
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing Pr… Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing Pr… Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing Pr… Michael Richardson
- Re: draft-kaiser-nd-pd-00.txt Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt Romain KUNTZ
- Re: draft-kaiser-nd-pd-00.txt Romain KUNTZ
- Re: draft-kaiser-nd-pd-00.txt Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt Andrew McGregor
- Re: draft-kaiser-nd-pd-00.txt Romain KUNTZ
- Re: draft-kaiser-nd-pd-00.txt Romain KUNTZ
- Re: draft-kaiser-nd-pd-00.txt Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing Pr… Alexandru Petrescu
- Re: draft-kaiser-nd-pd-00.txt (was: Announcing Pr… Alexandru Petrescu
- Re: Rapid Commit comment (was: Announcing Prefix … Alexandru Petrescu
- Re: Rapid Commit comment (was: Announcing Prefix … Michael Richardson
- Re: Rapid Commit comment Alexandru Petrescu
- Re: Rapid Commit comment Michael Richardson
- Re: vehicular communications, nd-pd, prefix excha… Alexandru Petrescu
- Re: default route's meanings (was: Rapid Commit c… Alexandru Petrescu
- Re: vehicular communications, nd-pd, prefix excha… Alexandru Petrescu