> "Alexandru" == Alexandru Petrescu writes:
Alexandru> But, consider that in V2V2I we may need not only Prefix
Alexandru> Delegation but also route exchange at the same time (IV
Alexandru> delegates a global prefix to LV, and IV and LV exchange
Alexandru> their self-formed ULA
When I presented this draft, Lorenzo explained that it's not good to
claim that ND is faster than DHCP (two messages instead of 4) because
DHCP has this Rapid Commit feature. To which I agree.
But, consider that in V2V2I we may need not only Prefix Delegation but
also route exchange at the same
Le 22/10/2012 18:58, Alexandru Petrescu a écrit :
Le 21/10/2012 23:45, Mark Smith a écrit :
- Original Message -
From: Alexandru Petrescu To:
sth...@nethelp.no Cc: ipv6@ietf.org Sent: Sunday, 21 October 2012
4:56 AM Subject: Re: Announcing Prefix Delegation extensions to
ND draft
Le 22/10/2012 19:06, Alexandru Petrescu a écrit :
Le 22/10/2012 02:54, Mark Smith a écrit : [...]
off. My point was that there is a method available for a relay to
discover DHCPv6 servers without the configuration issues related
to only being able to use a specific GUA or ULA unicast address.
Many thanks to John for his post. Yes, what is the problem we are trying
to solve here ? With NEMO, there is no problem related to changing IP
addresses ? NEMO is the solution for that. The in-vehicle router would
still get a new CoA while in the in-vehicle nodes would keep the prefix
initial
Le 25/10/2012 13:14, Michael Richardson a écrit :
Ralph Droms 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
Ralph Droms 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.
If an LV never ever wanted to get a PD from anything other than an IV, and an
IV could only ever expect to delegate to a LV, then I see no problem. On the
other hand, if these things do expect the same physical links to be used to
connect with other ecosystems (like home networks or hotspots) th
Hi,
Le 24/10/2012 02:56, John Mann a écrit :
Hi,
On 23 October 2012 03:54, Alexandru Petrescu
mailto:alexandru.petre...@gmail.com>> wrote:
Le 20/10/2012 23:51, Thierry Ernst a écrit :
Dear Alex,
Would you explain why the vehicle would need to get a new prefix
(a
Hi,
On 23 October 2012 03:54, Alexandru Petrescu
wrote:
> Le 20/10/2012 23:51, Thierry Ernst a écrit :
>
>
>> Dear Alex,
>>
>> Would you explain why the vehicle would need to get a new prefix (and
>> thus I assume configure all the nodes in the vehicle) every time it
>> enters a new area ?
>>
On Oct 23, 2012, at 2:05 PM 10/23/12, Brian E Carpenter wrote:
> On 20/10/2012 19:10, 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 t
On 20/10/2012 19:10, 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 pr
Le 22/10/2012 02:54, Mark Smith a écrit :
[...]
off. My point was that there is a method available for a relay to
discover DHCPv6 servers without the configuration issues related to
only being able to use a specific GUA or ULA unicast address.
Well, the use of multicast to identify the servers
Le 21/10/2012 23:45, Mark Smith a écrit :
- Original Message -
From: Alexandru Petrescu
To: sth...@nethelp.no
Cc: ipv6@ietf.org
Sent: Sunday, 21 October 2012 4:56 AM
Subject: Re: Announcing Prefix Delegation extensions to ND
draft-kaiser-nd-pd-00.txt
Le 20/10/2012 18:36, sth
Le 21/10/2012 02:45, Hesham Soliman a écrit :
The obvious conclusion to this argument is that a *lot* of DHCP
functionality will be duplicated in ND. Is this where we want to
go?
I'm coming from the DHCP side of the argument. In my world DHCP is
needed because it gives you a single place to han
Le 20/10/2012 23:51, Thierry Ernst a écrit :
Dear Alex,
Would you explain why the vehicle would need to get a new prefix (and
thus I assume configure all the nodes in the vehicle) every time it
enters a new area ?
Well, whenever MR of a vehicle changes its attachment point it would get
a ne
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 anoth
On Sun, 2012-10-21 at 17:54 -0700, Mark Smith wrote:
> > network. Mitigation would need filters everywhere, just in case.
> True, however you also have the same sort of vulnerability issues to rogue
> DHCP servers.
Unicast queries go only to the correct servers. Rogues don't get a look
in - except
Hi Karl,
- Original Message -
> From: Karl Auer
> To: ipv6@ietf.org
> Cc:
> Sent: Monday, 22 October 2012 10:52 AM
> Subject: Re: Announcing Prefix Delegation extensions to ND
> draft-kaiser-nd-pd-00.txt
>
> On Sun, 2012-10-21 at 14:45 -0700, Mark Smith wrote:
- Original Message -
> From: "sth...@nethelp.no"
> To: alexandru.petre...@gmail.com
> Cc: ipv6@ietf.org
> Sent: Sunday, 21 October 2012 3:36 AM
> Subject: Re: Announcing Prefix Delegation extensions to ND
> draft-kaiser-nd-pd-00.txt
>
>> There
On Sun, 2012-10-21 at 14:45 -0700, Mark Smith wrote:
> Actually it can, as the destination address for the server the relay uses
> can be the all-dhcp-serviers site-local (FF05:0:0:0:0:0:1:3) multicast
> address.
I have yet to see this in the wild, and would be interested to hear if
anyone actuall
- Original Message -
> From: Alexandru Petrescu
> To: sth...@nethelp.no
> Cc: ipv6@ietf.org
> Sent: Sunday, 21 October 2012 4:56 AM
> Subject: Re: Announcing Prefix Delegation extensions to ND
> draft-kaiser-nd-pd-00.txt
>
> Le 20/10/2012 18:36, s
Dear Alex,
Would you explain why the vehicle would need to get a new prefix (and
thus I assume configure all the nodes in the vehicle) every time it
enters a new area ?
Thierry
On 20/10/12 20:10, Alexandru Petrescu wrote:
Le 20/10/2012 18:42, Mikael Abrahamsson a écrit :
On Sat, 20 Oct 2
>
>The obvious conclusion to this argument is that a *lot* of DHCP
>functionality will be duplicated in ND. Is this where we want to go?
>
>I'm coming from the DHCP side of the argument. In my world DHCP is
>needed because it gives you a single place to handle dynamic address
>allocation, *and* it
On 10/20/2012 9:36 AM, sth...@nethelp.no wrote:
>> There is also the question of availability of DHCP software on smaller
>> platforms which have no SIM card. It may be easier to do this with ND
>> in smaller settings.
>
> The obvious conclusion to this argument is that a *lot* of DHCP
> function
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.
Le 20/10/2012 18:42, Mikael Abrahamsson a écrit :
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:
One point that guided towards choosing ND over DHCP is topology.
DHCP topology can be relatively complex with Client/Relay/Server,
whereas ND is simpler one-on-one.
There is nothing saying DHCPv6-
Le 20/10/2012 18:36, Mikael Abrahamsson a écrit :
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:
Right, parts of ND are handled in kernel in most OSes. But one
key part that would need to be modified is RA and that is
userspace. In linux that means mainly radvd, and curiously enough
that lacks
Le 20/10/2012 18:36, sth...@nethelp.no a écrit :
There is also the question of availability of DHCP software on
smaller platforms which have no SIM card. It may be easier to do
this with ND in smaller settings.
The obvious conclusion to this argument is that a *lot* of DHCP
functionality will
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:
One point that guided towards choosing ND over DHCP is topology. DHCP
topology can be relatively complex with Client/Relay/Server, whereas ND
is simpler one-on-one.
There is nothing saying DHCPv6-PD can't be done in a single device (the
router
On Sat, 20 Oct 2012, Alexandru Petrescu wrote:
Right, parts of ND are handled in kernel in most OSes. But one key part
that would need to be modified is RA and that is userspace. In linux
that means mainly radvd, and curiously enough that lacks RS which is
mostly kernel.
Sending of RA is u
> There is also the question of availability of DHCP software on smaller
> platforms which have no SIM card. It may be easier to do this with ND
> in smaller settings.
The obvious conclusion to this argument is that a *lot* of DHCP
functionality will be duplicated in ND. Is this where we want to
Le 19/10/2012 18:16, Mikael Abrahamsson a écrit :
On Fri, 19 Oct 2012, Behcet Sarikaya wrote:
It is not just implementing that code in one node. DHCPv6-PD
requires Delegating Router on a DHCP server somewhere and then
Requesting Router on the edge router (there was a proposal to
implement it on
Le 19/10/2012 17:50, Behcet Sarikaya a écrit :
Hi Mikael,
On Fri, Oct 19, 2012 at 3:08 AM, Mikael Abrahamsson
wrote:
On Fri, 19 Oct 2012, Alexandru Petrescu wrote:
Comments about the idea in this draft? About the problem?
What is the rationale for duplicating the functionality in
DHCPv6-
Le 19/10/2012 10:22, Philipp Kern a écrit :
Mikael,
am Fri, Oct 19, 2012 at 10:08:39AM +0200 hast du folgendes
geschrieben:
On Fri, 19 Oct 2012, Alexandru Petrescu wrote:
Comments about the idea in this draft? About the problem?
What is the rationale for duplicating the functionality in
DHCP
Le 19/10/2012 10:08, Mikael Abrahamsson a écrit :
On Fri, 19 Oct 2012, Alexandru Petrescu wrote:
Comments about the idea in this draft? About the problem?
What is the rationale for duplicating the functionality in DHCPv6-PD
into ND? If code needs to be changed, why can't that code change be
On Fri, 19 Oct 2012, Behcet Sarikaya wrote:
It is not just implementing that code in one node. DHCPv6-PD requires
Delegating Router on a DHCP server somewhere and then Requesting
Router on the edge router (there was a proposal to implement it on a
UE).
I know of implementations that do this in
Hi Mikael,
On Fri, Oct 19, 2012 at 3:08 AM, Mikael Abrahamsson wrote:
> On Fri, 19 Oct 2012, Alexandru Petrescu wrote:
>
>> Comments about the idea in this draft? About the problem?
>
>
> What is the rationale for duplicating the functionality in DHCPv6-PD into
> ND? If code needs to be changed,
Mikael,
am Fri, Oct 19, 2012 at 10:08:39AM +0200 hast du folgendes geschrieben:
> On Fri, 19 Oct 2012, Alexandru Petrescu wrote:
> >Comments about the idea in this draft? About the problem?
> What is the rationale for duplicating the functionality in DHCPv6-PD
> into ND? If code needs to be chang
On Fri, 19 Oct 2012, Alexandru Petrescu wrote:
Comments about the idea in this draft? About the problem?
What is the rationale for duplicating the functionality in DHCPv6-PD into
ND? If code needs to be changed, why can't that code change be to
implement existing standard instead of impleme
Dear participants to 6man group,
We just submitted "Prefix Delegation extension to Neighbor Discovery
protocol" draft-kaiser-nd-pd-00 available at:
http://tools.ietf.org/html/draft-kaiser-nd-pd-00
The context is vehicular environments, the goal to realize IP
vehicle-to-vehicle-to-infrastructure
41 matches
Mail list logo
