Jeroen Massar wrote:
Tony Hain wrote: [..]
What is the difference between having: 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 and: 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64
Nothing. If they announce the full deaggregate for the ULA space the impact would be the same as using PI deaggregates. The value is to have fc00:/8 lead to the demarcation for all the partners, rather than explicitly announce every partner subnet throughout their own organization.
Ok, if I understood correctly (guess a little drawing would help even more ;), you mean that, taking the above example, they will only have a 2001:db8::/48 and fc00::/8 route in their tables and nothing else? Otherwise they would end up with a large amount of /64's in their internal tables pointing to the partner.
Essentially this is the goal. Every situation will be different, like if there are 3 regional interconnects between a particular pair of companies that would likely mean 3 more explicit routes for the fc00/8 block, but not necessarily one for every partner in each region.
Also, they know that fc00::/8 is 'private' and that they need to firewall that in a different way. Which is a good property.
But how is this different from having a single default to the edge routers + firewalls, which take care of the routing tables to the endsite? You then have a single location to maintain, and those entries are then popping up only there and nowhere else.
That would be true if the demarcation for the default route and the private interconnect block were in the same place. If the Internet default and the private peering are on different routers sets then you need a way to split off the traffic.
Also, this sort of implies, from what I understood, that every host on the network will get multiple addresses, at least one from PI, and one from the ULA prefix. I do hope then that source address selection is being done correctly. Fortunately, fec00::/7 is at the top of the address space and thus can't easily be confused, like with 6to4 which is in the 'middle' and suddenly does get chosen for 2003::/16 and all other addresses, while the 2001::/16 prefix is used for 2001::/16 addresses.
Address selection is a mystery to most, but we need to fix 3484 to replace the references to SL with ULA, then the right thing happens. Tony