If you are saying multiple address for multiple interface, that's fine. but if you are talking multiple address for single interface, could you help to point out any IPv4 scenario except VPN, MIF is targeting at least half billion of subscribers who have this real problem, The problems you raised here is valuable to resolve, but MIF at the early stage may only solve some simple and easy to solve work, thanks -Hui > I'm saying there is a set of problems that exist if there are multiple > addresses associated with a host for any reason. This could be multiple > addresses on a single interface (including aliases and multiple v6 > prefixes advertised on the network segment), multiple addresses because > there are multiple active interfaces, multiple addresses because the > host supports both v4 and v6, multiple addresses because the host has > some sort of tunnel endpoint (which might be IPvX in IPvY, or an IPsec > tunnel, or mobileIP), multiple addresses because the host is behind a > NAT (any kind of NAT, including a v4/v6 NAT), and so on. > > And among those problem areas are: address selection (which differs > depending on the needs of the app, and the configuration of the network > to which the host is attached), referrals, sorting out policy conflicts, > sorting out non-policy related configuration, security, etc. > > Keith > >> Are you saying multiple addresses on one interface of the host? >> >> thanks >> >> -Hui >> >> >> 2009/4/21 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>: >>> Jari Arkko wrote: >>>> There has been some discussion on whether the key issue is merging >>>> configuration from multiple sources (the "DHCP view"), multiple >>>> interfaces (the "original view"), multiple default routers (the "routing >>>> view"), multiple addresses (the "IP layer view"), multiple >>>> administrative domains (the "operational view"), and so on. >>>> >>>> I would like to make the point that there is no single, perfect answer. >>>> Its easy to find examples where the key issues above do not capture >>>> everything that we want to capture (see, e.g., George's response to >>>> Keith). Its really about the combination of these issues. And I think >>>> that is the way it should be. >>>> >>>> The charter text that I sent out yesterday attempts to explain what the >>>> problem space is without prejudicing ourselves to a view from just one >>>> perspective (except perhaps through the group's acronym). I think the >>>> rest is work on the problem statement, and we should let the group write >>>> that. >>>> >>>> The IESG telechat where this could be approved is two days away. Does >>>> someone have a big problem with the charter as written, serious enough >>>> to warrant a change? >>> 1. I really think that the emphasis on "attachment to multiple networks" >>> is too narrow, as this is far from the only source of the problem. As >>> long as the WG is just trying to understand the problem and identify >>> existing solutions, it seems appropriate to broaden the scope to >>> consider the more general problem of multiple addresses per host. >>> >>> 2. I also think that, when considering the effect on applications, it >>> needs to be explicitly pointed out that p2p and distributed apps need to >>> be considered separately from client-server apps that many people regard >>> as representative. >>> >>> More generally I think that various kinds of effects need to be >>> considered (i.e. not just the effects on applications) and it would be >>> very helpful if the charter could lists some examples of these as >>> illustrations of the breadth of scope. That would minimize the >>> potential for the WG to start off with many participants thinking "_the_ >>> problem is X" when the actual problem is much broader.... and hopefully >>> get the WG in the mode where it tries to enumerate the various problems >>> and impacts rather than to try to nail down _which_ problem it is and >>> ignore the others. >>> >>> 3. I am a bit concerned by the charter's mentioning of BCP documents as >>> a possible output from the WG. I thought I had seen language in the >>> charter text saying that the group should write a BCP, but either I was >>> mistaken or that language has since been removed. But there's still a >>> BCP mentioned as a deliverable in the milestones. My concern is that >>> the WG will take this as license to try to define best current practice, >>> which I think is somewhat of a conflict of interest with trying to >>> identify the problem - especially given the broad scope. >>> >>> Keith >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf