As promised this morning, I'm reviewing
draft-ietf-v6ops-routing-guidelines-01.txt
First, as it stands, I do not see much difference with RFC2772, section
3:
3. Common Rules for the 6bone.................................... 3
3.1 Link-local prefixes...................................... 3
3.2 Site-local prefixes...................................... 4
3.3 Loopback and unspecified prefixes........................ 5
3.4 Multicast prefixes....................................... 5
3.5 IPv4 compatible prefixes................................. 5
3.6 IPv4-mapped prefixes..................................... 6
3.7 Default routes........................................... 6
3.8 Yet undefined unicast prefixes........................... 6
3.9 Inter-site links......................................... 6
3.10 6to4 Prefixes........................................... 7
3.11 Aggregation & advertisement issues...................... 7
draft-ietf-v6ops-routing-guidelines-01.txt:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3
2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3
2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4
2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5.4. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4
2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5
More important, I have a fundamental issue with this draft that I
already
mentionned in Montreal IETF. From the IETF66 meeting minutes:
Alain: The IETF is not the network police, and we can't say
anything on filtering policy. What we can do is say that these are
the trade-offs.
In its current form, with lots of 'must not be advertized' & similar
statement,
I cannot support this draft moving forward.
I would much favor a document listing 'special case IPv6 addresses'
and 'things to think about when routing them', explaning
what can go wrong if those prefixes are routed but specifically
NOT MAKING RECOMMENDATIONS to tell anybody how to run his network.