I'm co-author of this draft and web-page. Thank you for comments, Jinmei-san ,Stig.
> I've read the latest draft, but I'm afraid the document itself doesn't > help assess whether the ipv6 wg can support that or not, since it > mainly concentrates on the DHCPv6 specific issues. > > I believe what should be discussed in this group is the intended > scenarios (the "Practical Usage" section) described in this URL: At first, we planned to publish another Internet-Draft that describes practical usages of this DHCP option. But we found that these usages are almost the same as those written in Section 10 of RFC 3484. So, instead of writing another draft, I summarized some issues related to our proposal in this web page, which includes implementation status of address selection policy table, abstract of our proposing DHCP option and usages of it. To show all of you the related information at a glance. This is an excuse for not writing a Internet-Draft. ;) > >> As I posted before, this draft describes the RFC3484 policy table >> distribution (please refer http://www.nttv6.net/dass). >> > > I've read this page, too. My current impression is that "I see some > point, but I'm not sure if it's enough for introducing a new DHCPv6 > option". > > Specifically, > > >> Case1: IPv4 or IPv6 Prioritization >> > > I see this is a case where the automatic policy distribution may > help. But since the address selection by RFC3484 is much more > powerful than just selection between IPv4 and IPv6, I don't think this > can be a convincing usage if this is the only meaningful case. > > >> Case2: ULA or Global Prioritization >> Case3: Multicast Source Address Selection >> > > For these cases, using a non default policy table could resolve the > issue (and automatic policy distribution would help), but I personally > think this should be rather dealt with through a clarification for the > "default" selection rule, with the fact that site-local unicast > addresses were deprecated and ULAs are introduced. As you mention it, if ULA's address scope is defined like Scope(link-local) < Scope(ULA) < Scope(Global), the case 2 problem will be solved. As Stig has pointed out, however, defining an appropriate scope for ULA doesn't solve all the problems related to ULA site, which I described below. > > >> Case4: Global and Closed Mixed Connectivity >> > > This may look a valid use case superficially, but people will actually > wonder why ISP2 needs (or can have) global (non ULA) addresses, or > even any IPv6 addresses, to begin with, if it's not connected to the > global Internet. And, for example, if the closed network uses ULAs > and we clarify the "default" address selection policy, we'll be just > happy with the clarified default policy (we may also need the new > '/54' allocation policy as well, though). Or, if ISP2 just uses > private IPv4 addresses, we'll just be happy even with the current > default rules. Unless the usage example answers to this natural > question, I'm afraid this will look artificial (and thus cannot be > convincing). As for this point, we've had a related dialogue just before the previous IETF meeting on dhcwg ML, which I paste below. A VPN connectivity and a native IPv6 connectivity environment can be an answer to the first question. That is, a site has a native IPv6 connectiviy and also has a VPN connection, over the native IPv6 line, to another site that doesn't provide transit connectivity to a VPN-connected site. In this case, the same problem occurs as the case 4. In addition to this, what we believe is that ASP services like video streaming, ip phone, security service and home appliance maintenance will be getting into home networks and this trend has already started to happen. Even if each of these ASPs uses ULA, address selection problem occurs once one of them has a peering with another site or once one of them acquires another ULA block. thanks. Begin forwarded message: > From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[EMAIL PROTECTED]> > Date: 2005年3月10日 13:57:42:JST > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [dhcwg] comments on > draft-hirotaka-dhc-source-address-selection-opt-01.txt > X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) > > > > Junmei-san, > > Thank you for reading our draft in detail. > > | Substantial comments (or questions) > | > | 1. at least from this document, it's not clear whether we really need > | this kind of generic DHCPv6 option. In particular, the assumption > | in section 6 that ISP1 doesn't have global connectivity while ISP2 > | does seems very artificial. I cannot understand why we are > | suddenly led to this example. > > We believe that the closed network example is not artificial. There > will be some cases that users want to use multiple connections > simultaneously, such as global connectivity and VPN, and global > connectivity and some kind of ASP services (Video streaming, IP Phone > and maintenance of home appliances). Actually, some implementation > of IP phone already uses closed network model. > > | If this option is useful for a general multihome case, the draft > | should first discuss that case (rather than the odd-looking > | unbalanced example). But it does not seem to be the case to me (or > | at least it's not clear to me). > | > | What happens if both ISP1 and ISP2 have global IPv6 connectivity? > | Can this option help something in this case? > > CPE router can inform nodes which prefix should be used to a > destination prefix (in this situation, CPE router will inform > the nodes which uplink is selected as default). > > | On the other hand, assume neither ISP1 nor ISP2 has global IPv6 > | connectivity. Then isn't it enough to let the "longest-matching" > | rule of RFC3484 do the job for avoiding the trap of ingress > | filtering? > > Basically yes. > > However, end user network knows assigned prefix information only > and it has no information abut other prefixes that upstream ISPs > may have. This may be covered if routing information is available, > but in this case, other problem will occur (I'll describe below). > > | I also have a question from yet another point of view. In the > | "unbalanced" example of Section 6, the essential information for > | the "user router" seems the fact packets to A::/32 should be sent > | to ISP1 and others (including ::/0) to ISP2. This is, in essence, > | just routing information. Since we already need some kind of > | routing information in the typical PD usage, I don't see the need > | for the redundant information baring the new DHCPv6 option. > > There are some cases that address selection policy cannot be created > from the routing information. > > For example, > - a router that advertise routing information and a DHCP-PD server is > the different node. > > - a DHCP-PD server wants to assign multiple prefixes that have > different selection policy. > > In these cases, it is generally impossible to make relationships > between routing information and assigned prefix. > > > | BTW: in the case of the PD usage, the "assigned" prefix (e.g., > | A::/48) should be provided in the PD framework, so this information > | in the SASP option seems redundant. > > If the DHCP-PD router assigns only one prefix, it may be surely > redundant to have the prefix value in SASP option. But it is > necessary to keep the relation of assigned prefix and SASP policy, > when it delivers multiple prefixes and multiple policies. > > | I see we may need some new mechanism between the user router and > | end nodes in order to relate the routing information (e.g., the > | default route is the path to ISP2) to source address selection > | rules, in order to avoid the ingress filtering trap. But, in this > | case, I think we only need a single mechanism, whether it's DHCPv6 > | or RA. Remember that even an end host that configures addresses by > | stateless address autoconfiguration may still need DHCPv6 for > | getting (recursive) DNS server addresses. Similarly, even an end > | host that configures addresses by DHCPv6 will still need RAs to get > | on-link prefixes. So, a single mechanism would be enough for > | providing source address selection rules, whether it's RA or > | DHCPv6, and whether receiving node uses RA or DHCPv6 for address > | configuration. > > Well, I think I have to look into more about this issue, whether DHCP > is always vital for every node or not. > > | BTW: the source address selection problem with ingress filtering is > | exactly what one of general multihoming issues. So, one may ask > | for discussing this in the context of (e.g.) multi6 wg. We'll at > | least need to be asked why we cannot use solutions being considered > | in multi6. > > Surely, ingress filtering issue in multiple global network connectivity > environment is multi6 matter. Our proposal can solve this issue as I > stated above, and I believe that our proposal can go well with the > coming multi6(shim6) new proposal for the hints of source address selection. > > Actually, we made a presentation at multi6 meeting in DC, and multi6 > chairs advised us multi6 does not target the closed network case. > > > | Semi-substantial comments > | > | 2. the scenario described in this draft seems to assume (perhaps > | implicitly) that the user router can get all the prefix information > | (from ISP1 and ISP2) at once. However, the PD procedures with the > | ISPs should in general be asynchronous events. So, the user router > | should somehow deal with the asynchronous information for providing > | consistent rules with end nodes. It's not very clear from the > | current draft on how the user router behaves wrt this concern. > | (Perhaps this is not a serious issue...I'm just not sure about this > | from the current text) > > This asynchronous behavior doesn't lead to such a serious trouble, > I agree that I have to mention about it too. > > | 3. In section 6, the draft says: > | > | o End nodes set up their IPv6 addresses by using a stateful DHCPv6 > | function or receiving router advertisement message. They also > | request the SASP option by transmitting Information-Request > | messages to the router. > | > | But if the end node uses DHCPv6 for address set-up, it should also > | be able to get the SASP option in this procedure; I don't see why > | the node needs to transmit Information-Request in this case. (But > | see also the more fundamental question above). > > Absolutely. I'll correct it soon. > > | 4. Also in Section 6, > | > | o When the requesting client detects a change in a delegated address > | or address prefix, it requests the Source Address Selection Policy > | option again. > | > | This statement is not very clear to me. What is the "requesting > | client" in this context? Is it the user router, a end node, or > | both? (Perhaps the definition in Section 3 is not very clear in the > | first place) Also, how does it "request" the option again? > > I fully agree that this sentence is surely ambiguous. > > What I wanted to say is: > > - a prefix and a source address selection policy is strongly bound. > - when a prefix is invalidated, the corresponding source address > selection policy also has to be invalidated. > > We'll rewrite this part. > > | 5. In section 7, > | > | A malicious DHCPv6 client may be able to mount a denial-of-service > | attack by sending repeated requests for the Source Address Selection > | Policy option, thus exhausting the DHCP server's resources. > | > | I'm not really sure about the point of this statement. What kind of > | "server's resources" are concerned here? Since the SASP is quite > | stateless, shouldn't the "malicious" client consume further > | "resources" such as address/prefix pools? Or, does this sentence > | considers the processing load at the sever side? But if so, > | > | To guard against attacks, both DCHP clients and servers SHOULD use > | DHCP authentication, as described in section 21 of RFC 3315, > | "Authentication of DHCP messages." > | > | I don't think this is very accurate. A malicious client can still > | bother the server, consuming the server's resource of processing load, > | by sending repeated requests with bogus authentication information. > > We will also rewrite security consideration section. > > | Editorial comments > | > | 6. In section 1, second paragraph > | s/packet- forwarding/packet-forwarding/ > | > | 7. there's a mixture of "usable" and "useable" in the second bullet of > | Section 6. This should be consistent. > | > | 8. In section 7, last paragraph > | s/"Authentication of DHCP messages."/"Authentication of DHCP > messages."/ > | (there's a redundant white space) > > Thank you very much. > > Yours sincerely, > -- > Tomohiro Fujisaki > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/dhcwg -- Arifumi Matsumoto <[EMAIL PROTECTED]> Ubiquitous Computing Project NTT Information Sharing Platform Laboratories TEL: +81-422-59-3334 / FAX: +81-422-59-5652 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
