Things to Think About Eliot Lear IETF 59

What the document ISN’T This is not a requirements document –We did one of those already – RFC 3582 Not an architectural layout document –Although it addresses some points that might show problems with various architectures Not a position paper –The author identifies issues, and takes the sole position that authors of proposals should provide truth in advertising.

What the document IS Draft-lear-multi6-things-to-think-about-01.txt A collection of questions that address operational issues that should be addressed Focused on MULTI6, but not exclusive to it –This document may be applicable to HIP and HIPRG Relatively Short –As requested by AD & WG chairs Comments to the WG or to me.

Key Areas On the Wire Security Name/binding issues Applications Backward Compatibility Legal The astute will observe that many of these issues are intimately related.

On the Wire Are there packet format changes? If so, at what layer? –And why is that the correct layer? What is the transport layer impact? –Pseudo header issues What impact if any is there on packet sizes? –Ponder fragmentation concerns HIP in particular may have some concerns here Is there any additional latency? –Are additional exchanges required? –By all or just by multihomed devices?

Security If the implicit binding between name and location is changed, how is the new binding secure? –Against Interloping? –Spoofing? –Etc? Are there new potential DDOS opportunities? –Perhaps in terms of processing? This meeting: What external infrastructure is required? –CRLs? CAs?

Name / Binding Issues What is the lifetime for a binding? How is the binding updated? Is a new namespace introduced? –If so, what does it look like? –How is it managed? –How does it related to the DNS? What upstream provider support is required? What dependence is there on middle boxes and support servers? –Aka, name servers, home agents, etc? –Whose administrative domain will those be in?

If DNS is used… Are there any circular dependencies with the routing system? What coherence requirements are there? What RRs are used? What do you do with the name? How do you handle “Two Faced DNS?” How does the host know its identity? What additional load is anticipated on name servers? DNSSEC performance an issue?

Applications Is a new calling interface required? –How does it differ from existing call interfaces? –What happens with getaddrinfo(), gethostbyname(), etc? If not, does a recompile (or less) get you there? How do applications handle referrals? –FTP, SIP, H.323

Backward Compatibility How will this solution work with “old” IPv6? Can IPv4 devices take advantage of the same mechanism? How do “multi6” hosts and applications interact with non-multi6 hosts? Do non-multi6 sites have to make any changes? Is there a performance hit for non-multi6 hosts and applications? Does multihoming require a change in the management model? –Are there new support concerns?

Here are two tests… How would your solution be applied at an IETF conference like this one? Have you developed your method sufficiently to try it in a lab?

Legal Are there any trademark issues introduced? If a new name space must be administered do we need an ICANN-like function?

The goal of this document and this presentation is that authors should compare results and perhaps benefit from each others’ work.

What do you do with all of this? Crate a matrix and compare results Perhaps merge solutions or borrow mechanisms Possible to select multiple complimentary approaches (say at different layers)

Questions for this group 1.Have people read the document? 2.Is it useful? 3.Does it require an additional level of detail? 4.Is it missing things? 5.Is it done? 6.Should it be done? Should this be a live document for a while longer as we learn more? 7.Or is stability of this document important for comparison?