Comments on draft-nward-6to4-qualification-00

[Christian Huitema <huitema@windows.microsoft.com>]

As Brian kept mentioning this draft and encouraged us to review it, I just did.

Nathan's draft proposes to verify 6to4 connectivity before configuring the 6to4 interface. The verification proceeds in two steps. First, verify that a well known IPv6 6to4 address is reachable over 6to4, by means of a ping test. Then, verify that a well known native IPv6 address is reachable through the default 6to4 relays, again by doing a ping test. If these two test succeed, the interface is qualified and routes are installed.

This verification is a good idea. There is no point in configuring 6to4 if it does not work, especially if other technologies like Teredo could be used, or if remedial steps could be taken, like for example trying a different relay address. Nathan's draft addresses a real need, and I would like it to be adopted as a work item.

The draft is indeed in an initial proposal. I have several comments, some technical and some editorial. First, the two editorial comments:

* The procedures can be summarized in a single paragraph. The draft would be easier to understand if the abstract included such a summary.

* The draft uses place holder acronyms like TBD, TBD1, TBD2. I suggest giving actual names to these variables, e.g. "the 6to4 connectivity test address", and explaining the names in a "notations" section at the beginning of the draft.

Now, the technical comments:

* the draft instructs IANA to allocate a 24 bit IPv4 prefix. Good luck with that. I suggest considering a design that does not carry this requirement.

* the draft requests configuration of both a 6to4 address (TBD1(6to4)) and the corresponding IPv4 address (TBD1(IPv4)). It would be simpler to just configure a 6to4 address, and algorithmically extract the IPv4 address from that 6to4 address.

* The draft assumes that the tests are conducted using two well known IPv6 addresses. These addresses are likely to receive a lot of traffic. Since the draft attempts to cure issues caused by the use of anycast addresses, I presume we do not expect to use anycast for load sharing. How then do we expect to sustain the load, and provide adequate reliability?


-- Christian Huitema