Warly wrote:
>> Or are the user PC IPv6 addresses hard-coded on the PC? (e.g. I 
>> sell this PC to this end user and its address I decide to be e.g. 
>> 1::1).
> 
> PC will have, first at least, a fixed IPv6 address in its 
> configuration. I am doing the PCs configuration in our production 
> center (my company is also manufacturing the PCs)

Hardcoding addresses into sold PCs is of course a little preferable
idea, especially knowing that it may prove to be a chicken&egg problem
to change that address remotely (with the management system relying on
that address).  Second, boxes at home that need to be rebooted every
time a parameter changes aren't preferable either.

> Later on I may use DHCPv6, but as far as I could read, this is not 
> yet working very well through IPSec.

WEll, depends.  If OSPFv3 works through the IPsec tunnel then DHCPv6
will work too.

>>> Through this VPN IPv6-in-IPv4 network the user can access the 
>>> IPv6 backbone, or other computers in the same network with global
>>>  IPv6 addresses.
>> I'm not sure how this can work.  Generally speaking I'm used to VPN
>>  to mean exclusively IPv4-in-IPv4 with an initial IKE exchange. I'm
>> not sure whether IPv6-in-IPv4 is still called 'VPN'.  Secure 
>> IPv6-in-IPv6 is maybe ssh... but I'm not sure what you mean 
>> precisely by IPv6-in-IPv4 VPN.
> 
> Well, technically speaking, this is some kind of UDPv4 encapsulation
>  of IPSecv6 packets.

So the UDPv4 headers are unprotected?

>>> This is an interesting point. I was thinking that household will 
>>> preferably masquerading techniques for internal network,
>> Well there are no masquerading techniques for IPv6, as they exist 
>> in IPv4 linux parlance.  There's no IPv6 NAT currently (no 
>> software, no standards).
> 
> Ok.
> 
>>> The current goal is to include all the computers in a IPv6 
>>> network for remote management and peer 2 peer exchanges with the
>>>  collateral effect to have an IPv6 ready computer and a uplink to
>>>  the IPv6 backbone. So the IPv6 connectivity is not the primary 
>>> target, but somehow be practical.
>> Makes sense.  It sounds as if you want to build an IPv6 network 
>> that looks like an overlay network over the IPv4 network.  This 
>> makes a lot of sense for IPv6 in general.  The details are 
>> relevant.
> 
> This is exactly what I would like to do. And as the number of 
> households could be several tens of thousands, I wanted to be sure my
>  IPv6 addressing policy was correct and admitted.

Yes, this should be identified.  As you already said, thousands of
prefixes can be encoded in as little as 16bits between positions 48 and 64.

Other side remarks...

I'd say that if the new box is the first hop out of the home then one
could easily use 6to4 technology - widely available.  If the box is
_not_ the  first-hop out of the home, but somewhere deeper in the
household network, behind the IPv4 NAT running on the first-hop existing
box, then it's different, 6to4 through NAT is working badly (depending
on the type of NAT).  Commercially speaking, I think one has more
chances to sell non-first-hop boxes because the first-hop boxes are
already largely controlled by huge market players.  Or you may be part
of those.

And of course there are many other variables.

A sometimes safe way is to reuse to the maximum the widely available
software, understand the standards evolution and be ready when things
(e.g. DHCPv6) arrive.  Designing an IPv6 addressing architecture that
ignores DHCPv6 Prefix Delegation is probably prone to later change.

Anyways, great opportunities.

Alex

_______________________________________________
Users mailing list
Users@ipv6.org
https://lists.ipv6.org/mailman/listinfo/users

Reply via email to