Hi Jari, all, After reading this email and reading all the responses I think a few comments are in order. Generally speaking, I would think that when given a choice between a "one size fits all" solution versus one solution per protocol, most people would choose the former. However, I don't think the choice is so simple as some of the responses seemed to imply.
I think it is ill-advised to take a decision on this without understanding the scenarios, and the resulting requirements from those scenarios. Additionally, we need to consider how each of the protocols using the solution actually work. I'll list the scenarios we (authors of one of the solutions) had in mind and let others comment or add their own scenarios. Regardless of the approach, the solution we had in mind would transfer flow descriptions and binding information between the flow in question and one or more of the mobile node's addresses. The sender of this information is the mobile node. The receiver is either a correspondent node or another intermediate node. If we use the terms HA/MAP then we're implying the use of MIPv6. So I'll stick to generic language. Now, each of the protocols you mention below (HIP, Mobike, SHIM6 ...etc) have their own way of identifying the sending node to the receiver of the signalling. This identity is obviously essential for securing the signalling. Furthermore, they're all different in this regard. So I don't think having one solution that fits all is a simple task. Even within one protocol, the security requirements are different depending on the node receiving the signalling. MIPv6 is the perfect example for this case. Can we just assume that IPsec or AAA will work with a CN? I don't see how. Also, some entities don't exist in all protocols, e.g. the HA/MAP. So even if we go with "one solution" it would have to incorporate several modes of operation (at least from the security perspective) to work for all the different protocols. Another question to ask here is what is the real benefit of having one solution? I'm not talking about saving documents, I mean a real benefit to an implementer. If the flow descriptors need to have the same format then that's easily done and reusable for implementers. But that doesn't require one transport protocol. On the other hand, there are examples of protocols that incorporated the same function without having to coordinate one protocol across the board. A recent example is the use of IPv4 and IPv6 addresses in mobility protocols, which was done in MIPv6, MIPv4 and I think shim6 without having to come up with a single solution. Regardless of the outcome of this discussion, I hope we can get specific with the comments that highlight the benefits of having one Vs several solutions. I urge people to look at the bullets at the end of Jari's original email and consider them when they make up their mind for one approach Vs another. Hesham > I would like to lift up one issue from the Monami6 WG > to a more general discussion. Monami6 is developing an > extension to Mobile IPv6 / Nemo so that a mobile node could > register its presence in multiple locations simultaneously. > One of things that they expect to be able to do is to control > what traffic goes to what care-of address; this flow to this > address, and the other flow to that other address. Mobile nodes > can obviously decide by themselves what outgoing interface to use. > However, in order for a home agent to deal with return traffic > properly, the mobile node has to tell it what policy to > employ. > > The working group has debated between a number of different > approaches for doing this. In one approach, draft-soliman- > monami6-flow-binding the mobile node adds a filter to a Mobile > IPv6 Binding Update to tell what traffic should use this binding. > Another approach, draft-larsson-monami6-filter-rules, decouples > the policy exchange from the mobility protocol. The policies are > exchanged at a different time (typically earlier) and carried by a > different protocol (in this case over UDP). Yet another draft, > draft-mitsuya-monami6-flow-distribution-policy also separates > the mobility protocol and policy transfer, and carries > the policies in HTTP. > > Monami6 should of course decide how they want to design this. > But this may be an interesting debate from a more generic point > of view. Do we have input for them? For instance, are there needs > in HIP/Shim6/Mobike space for similar functionality? Should the > designs be tailored for each of these situations? Is there some > advantage or disadvantage in looking at a generic solution? > Would a generic solution be doable? > > Without going into too much detail about the specific proposals > it seems that there are actually a number of different topics here: > - carrier protocol choice > - policy container format > - timing of the policy exchange > - securing the transfer > - etc > > Thoughts? > > Jari > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
