[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] IPV4 is nearly depleted, are you ready for IPV6?



For testing, I use a random subnet of feff::, they are only *site*-local
(link-local = only on the same physical network like ethernet, etc. not
routed at all; site-local = only local to your
company/network/LAN/whatever, but those packages can be routed but will
not be forwarded to the Internet) and perfect for testing. Link-local is
not good for testing, because site-local addresses are depended on the
network device; if you want to ping another host link-local, you have to
add the device like:

ping6 fe80::xxxx:xxff:fexx:xxxx%dev  (the x is the mac address, dev the
device in ip link / ifconfig)

This is not really handy and those networks don't behave like real IPv6.
Site-local is like IPv6 on the Internet; only reserved for local /
testing use.

NAT has its problems, but with IPv6 nobody is forced to use NAT - but I
think denying it completely will destroy some little areas where NAT can
be really cool...

Am 07.12.2010 13:53, schrieb Simon Hobson:
> Jonathan Tripathy wrote:
>
>> As for the NAT issue, indeed a really do love NAT. I find it a huge
>> culture shock and unsettling that in an IPv6 world, all internal
>> machines will have public routable IP addresses. Does this mean that
>> the traditional "Edge Firewalls/NAT routers" would become filtering
>> bridges? As surly the world couldn't depend solely on host-bases
>> firewalls... (could we?!)
>
> Err, traditionally all hosts once had public routable addresses. NAT
> is a new fangled abomination that really does cause lots of problems
> for lots of traffic - I'm involved with VoIP at work, anyone who'se
> dealt with that and NAT will know what I mean.
>
> In practice I think your edge (NAT) router/firewall will become an
> edge router/firewall with your own IPv6 subnet on the inside of it.
>
>> I guess if each "internal" network in the world had it's own IPv6
>> subnet, then we could just use a standard firewall-router (in no-NAT
>> mode). However it just seems like extra trouble to go and obtain an
>> IPv6 block from the responsible body. For example, I spin up many
>> test internal networks on a daily basis just to play around with them
>> - I don't really want to "register" these networks.
>
> You can use link-local addresses for such testing, and I believe there
> is also a "private" range set aside for use within an organisation -
> ie it's routable, but only between sites internal to an organisation.
>
> As for public addresses, AIUI, unless you are really big then you will
> never get your own subnet allocation - this being one of the problems
> with IPv4.
>
>
>
> If any of the below is wrong, then I'd be more than happy to be
> corrected !
>
>
> Apart from address exhaustion, one of the problems with IPv4 is the
> size of the global routing table which needs to track the location (in
> network terms) of every allocated and active block. So if you go to
> <your local registry> and get an address block allocated to yourself,
> then you or your ISP will need to advertise that block via BGP4 and
> the route will propagate around the world. I don't think it takes too
> much imagination to realise the number of such allocations.
>
> If you just use a sub-allocation from your ISPs larger block then that
> isn't an issue - the ISP will only advertise a larger amalgamated
> route for the entire block. BUT you then are tied to that ISP.
>
> AIUI, in IPv6 you have to be really, really big to get a direct
> allocation. Everyone else gets a delegated chunk from their upstream
> provider and in principal, all traffic routes upwards to a small set
> of supernodes. Thus the global routing table stays small. I guess ISPs
> will get together at exchanges and privately exchange routes, but this
> won't add to the global route table.
>
> At each level, bodies will get a chunk delegated from above, and if
> you take a connection from two ISPs for redundancy/aggregation then
> you will get two different delegated blocks. You cannot go and get
> your own block and have it routed via the two ISPs.
>
> In practical terms, all hosts will expect to be multihomed, and all
> this (including changes of address when you change ISP) will be hidden
> in the DNS.
>
> From what little I know of DNS with IPv6 this isn't as bad as it might
> seem. AUIU, AAAA records are heirarchical unlike IPv4 A records which
> simply specify "an address". An AAAA record specifies addresses
> relative to a prefix - so in theory you could change everything by
> just changing the single record that specifies the prefix.
>
> I think DNS will become FAR more important with IPv6 - for the simple
> reason that few people are going to be able to remember real IPv6
> addresses ! I think this is a good thing, one of the things that irks
> me are sites I have to work at where the DNS is broken and no-one
> cares (or probably even realises) since it's so easy to just use
> 192.168.1.xxx.
>
> In the case of someone changing ISP - their prefix will change, and so
> they'll have to update that element in their DNS. But once they've
> done that, they will still be able to access stuff by the same DNS
> name (eg main-server.ho.somecompanyname.com). As long as us Techies
> have got it all right, the end users should neither see any difference
> nor have any need to care.
>
>
> That's what I know of the theory, now all I need to learn is how to
> put it into practice.
>
>
> Oh yes, and one upside I can see is that HTTPS will be easier to use.
> At present, you either need an (expensive) multi-host certificate or a
> separate address for each host. Given the shortage of addresses, few
> providers will give you your own address on a shared server without an
> extra charge - but that shouldn't be an issue when we all have so many
> addresses.
>

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.