IPv6 working group, part 2
Based on a bunch of lectures given at ripe64 at the IPv6 working group
Experiences in setting up Automatic Home Networking
- Networks shall have address space
- routers shall know where to send packets
- names resolve to addresses
- human touch is not required
All this can be done with only one subnet. But is that enough?
- Guest vs private vs utility
- Differring link technologies gigabit ethernet vs sensor networks
- Explosion in the number of devices in our homes
- You’ll buy a new device anyway, and just chain it with the rest of your network
The danger is that people will think IPv6 too hard to use, or that you get IPv6 networks connected via NAT66.
IETF home networking working group. Goal is to support multiple networks and multiple routers with prefixes and routing automatically configured and services discovered throughout the network. They are using DHCP prefix delegation, RAs, RIP/OSPF for routing, and add small enhancements for autiomatic selfconfiguration.
Follow the IPv4 architecture in the sense that you plugin a v6 router where before you had a NAT44 devices. They also worked out ways by which these routers can parcel out the /64 that each of them needs, given that at least one of them knows which address space the network can use.
Real world example in Jari Arkko’s home:
Runs OSPF, automatically configures the routers to do it, parcels out the address space, and advertises the prefixes as needed. , it also automatically configures NAT64 and adds automatic DNS server discovery.
Most people think in terms of dual stacks and that is recommended for most, but they are different from pure v6. On v6 side you need DNS autodiscovery. Also if you are using NAT64, you might find it includes a DNS server that fixes the information, and you want to use that behind the NAT64 device, but not elsewhere, because that information is incorrect elsewhere.
Handling the different eqipment profiles and standards
How to get a new feature like IPv6 into a standard product?
- Demand from a customer
- Demands from end users
- roadmap decisions
- industry developments in general
But again, there are many standards (eRouter, IEEE, ITU, RIPE, ISOC, etc).
IPv6 profile for the german public administration
Guidelines to introduce IPv6 in German administration. Long growing IP networks with overlapping 10.* network adresses, interconnection was horrible with several NAT44.
VOIP and video conference were highly desired.
First they got a /26 from RIPE for the whole german public administration. Procurement has been demanding IPv6 support, and vendors were offering “some” IPv6, but this was not useable in real life. Local administrators want guidelines, because they fear making mistakes.
They made an IPv6 profile, defining migration guide, …
What to migrate? segmens (provider, consumer, transfer, coupling networks), security zones, …
Too many RFCs, so they had to simplify. They looked at otehr profiles and created structuring. And they restructed requirements into functional blocks.
They did another matrix for the applications, but the structure was a challenge, because they needed to define dependencies between applications.
replacing RIPE 501
A Draft replacement was cycled through the mailing list and put to last call, suggestions were made, authors decided to edit the draft based on the feedback.
- Include resuts of IP6434,
- fix the IPSec requirements,
- make deprecation of type 0 routing headears mandatory,
- make things depend on ipv4 conditional ‘if support for tunnelling and and dual stack is required’.
- ipv6 host-to-router
- MLDv2 snooping made optional for consumer grade stuff
- updated 3gpp references
- IPSec is not optional, but is not really mandatory (users are encouraged to make it mandatory when preparing a tender)