RE: IPv6 WG Last Call on IPv6 Global Unicast Address Format for the 2000::/3 Prefix
The idea is that developers must not hardcode any assumptions. The reason they must not is because IANA will later delegate the currently unassigned parts of the space to a purpose we don't know, including possibly an extension to Global Unicast. The proposed text reads as if the IANA delegation is the main point and the implementation note being just a side note. So if the implementation concern is the main point of the paragraph why not say this explicitly with something like Even though currently only 2000::/3 is being delegated by the IANA, implementations should not make any assumptions about 2000::/3 being special, since the IANA might later delegate currently unassigned parts of the IPv6 address space to the purpose of Global Unicast as well. Erik IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
Thomas, See my comments inline: We don't know, and 60 seconds is a compromise value anyway. But there seemed to be WG consensus that a default timeout is needed, since otherwise we are licensing implementors to create hard state. The authors have been round and round this many times, and this was the best we could come up with. (more comment on this below) Well, I have a basic problem with a default timeout of 60 seconds. Heck, a temporary routing glitch can cause a loss of traffic for 60 seconds, yet the TCP sesssion doesn't go away that quickly. So 60 seconds seem like a rather odd compromise value. Seems too short to me. Presumably the node can re-create the state it needs after the gap. Since there was a long gap, there should be no reordering issues (in case the new state for example determines a different next-hop interface). For reference, RFC 1883 defined a lifetime value of 6 seconds. Not really relevant, as that had to do with the now discredited opportunistic caching that is explicitely deprecated by this document. Well, IMO the default lifetime has no other function than enabling opportunistic caching (if everything is based on a explicit set-up, the lifetime for each flow can be set up individually, and no default is needed). As a consequence of adding the default lifetime, I removed the SHOULD NOT that prohibited setting up state without a set-up mechanism. As I said above, I do not know any use of flow-specific state without the support of a flow state establishment method. But if we do not define a default lifetime now, it cannot be added later. Also, it seems logical to have *some* pause before a previously used flow label value should be re-used for a new flow. I don't necessarily disagree with the need for a default lifetime. But I think 60 seconds is too short. It seems to me that it would be better to tie it to something more meaningful, like TCP lifetimes. At least, if we're just picking a value out of the hat. Why is 60 seconds better than 2 minutes? Why is 2 minutes wrong compared to 1 minute? Let me state it differently. What I'm hearing is that we want a default, but that 60 seconds has been pulled out of thin air. I can't evaluate whether that is a good default or not, because I don't understand the tradeoffs. I'm arguing that its too short, but the reasons for keeping it short don't seem (to me) to be very rigorous. What are the tradeoffs here that would lead one to pick a longer or shorter value? Some thoughts: There is a cost associated with a short default, in that routers will be forced to rebuild the flow state more frequently. Given that temoporary routing issues can easily last more than a 60 seconds, and that a normal TCP connection/flow will sometimes not send traffic for 60 seconds, I worry that this cost is relatively high. Is that cost justified? There is also a cost for the default being longer on hosts, as they need to not reuse flow labels too quickly. The issue seems most acute across reboots. Is it substantially more overhead for a host to not reuse a flow label for (say 5 minute) vs. one minute? I don't think so. Are there other issues that should be considered here? If e.g. random initial value and sequential allocation is acceptable after reboot, then there is no additional cost to the host on even longer than a few minute timeouts. But a short default timeout should not be a burden on routers either. There are two cases: 1) opportunistic set-up: the overhead of setting up the state must be negligibly small, as the router needs to be prepared to set up state for each incoming packet (in the worst case scenario). If so, the difference between 1 and 2 minute default lifetime should be of no consequence 2) Flow set-up with a flow set-up mechanism: The mechanism can set whatever lifetime it wants. If the mechanism is concerned by TCP timeouts, then the minimum lifetime being set up with that mechanism is likely to be 2 minutes (?). Some other mechanisms could utilize lifetimes considerably longer (e.g. 1 hour), depending on the cost of setting up and maintaining the state with that mechanism. My take is that for 2) the default lifetime value has no real meaning (other than hosts need to keep the labels in quarantine for the default duration, even if the flow set-up resulted in a shorter lifetime, because there could be a node in the path not taking part in the mechanism, but opportunistically caching the flow). For 1) even 6 seconds should be fine. WG chairs (collectively) insisted on the definition of the default lifetime, and there were no opposing voices on this from the WG. I do not think the default lifetime should have anything to do with TCP timeouts, as long as it is long enough to not cause any reordering issues. But this is not an issue for me, any value is fine, especially if someone
Re: a few comments on anycast mechanisms
Well, this was only proposed for TCP. I don't know what this refers to but the original message from Pekka commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to those comments. That draft has this in the abstract: Today, the use of IPv6 anycast is limited. This document proposes a mechanism by which TCP/SCTP and stateful protocols using UDP can So the draft fron Brian and me sure proposes using this for more than just TCP. I'm not sure if we should consider something similar for UDP. Basically, UDP based protocols can be easily written to handle the peer address change on the application layer. However, if we want to support existing UDP applications that for example connect() their socket to a destination address, we'd need to device something similar for UDP as well. Do you think we need this? I don't know about easily - they would need to provide the secure binding mechanism themselves. I think it makes sense to try to figure out a mechanism which can be applied to multiple stateful protocols without requiring every such protocol to roll their own. At one end of the scale one could consider doing do changes to the transport at all by hiding it all in a MIPv6 binding cache. Thus the transport protocol would think it is actually talking to the anycast address. I think such an approach has problems since the fact that the transport is not aware that anycast is used means it can't take specific actions when things fail (like trying to create a binding to a different member of the anycast address). Providing this transport protocol aware anycast model means that there will be some changes to the transport protocol, but I think one can avoid placing all the mechanisms in each transport protocol. Erik IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
[EMAIL PROTECTED] wrote: ... Would everyone be happy with 2 minutes? I would. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: a few comments on anycast mechanisms
On Tue, 2003-02-25 at 15:28, Erik Nordmark wrote: Well, this was only proposed for TCP. I don't know what this refers to but the original message from Pekka commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to those comments. That draft has this in the abstract: Today, the use of IPv6 anycast is limited. This document proposes a mechanism by which TCP/SCTP and stateful protocols using UDP can So the draft fron Brian and me sure proposes using this for more than just TCP. Right, I had forgotten where the thread started. I was referring to Pekka's idea of using an ICMP error response as a simple redirect indication to a TCP sender and authenticating the ICMP packet by checking the TCP sequence number in the ICMP payload. I'm not sure if we should consider something similar for UDP. Basically, UDP based protocols can be easily written to handle the peer address change on the application layer. However, if we want to support existing UDP applications that for example connect() their socket to a destination address, we'd need to device something similar for UDP as well. Do you think we need this? I don't know about easily - they would need to provide the secure binding mechanism themselves. TCP has the problem that it simply can't be used with an anycast address without changing the protocol or somehow handling the binding transparently on L3 (as in MIPv6). UDP doesn't have this problem; at most the applications need to be changed to react correctly to peer address change. I didn't consider the above from the viewpoint of authenticating the binding. I can see that the authentication could get quite involved with UDP. I'm not sure it's wise to do it transparently in all cases. I guess the RR mechanism could be adapted but there are some problems. Some of the problems relate to figuring out what constitutes a session with a UDP application. A connectionless socket could be used to communicate simultaneously with multiple peers, the protocol could just be a one-shot request-reply interaction, or the flows could be uni-directional, etc. Also, as I pointed out earlier, the RR mechanism in MIPv6 affords the CN some protection against DoS at the expense of the MN. In draft-haberman-ipv6-anycast-rr-00 the anycast server takes the role of the MN, which means that it draws the short straw when it comes to DoS protection. I think it makes sense to try to figure out a mechanism which can be applied to multiple stateful protocols without requiring every such protocol to roll their own. That's a good goal. Different applications might have different requirements, though. Some might require that the binding is authenticated, while others might value a speedy redirect, even if unsafe. At one end of the scale one could consider doing do changes to the transport at all by hiding it all in a MIPv6 binding cache. Thus the transport protocol would think it is actually talking to the anycast address. I think such an approach has problems since the fact that the transport is not aware that anycast is used means it can't take specific actions when things fail (like trying to create a binding to a different member of the anycast address). True. It is also worth asking what is the proper granularity for storing the binding: per host, per flow, or something in between? Do we want to redirect all applications to the same unicast address, or should we allow different flows go to different unicast addresses? Providing this transport protocol aware anycast model means that there will be some changes to the transport protocol, but I think one can avoid placing all the mechanisms in each transport protocol. Maybe some basic L3 mechanisms, like the binding cache and RR, could be made available to applications and transport protocols as a toolbox via an appropriate service interface. Each anycast user could then use this toolbox in the most appropriate way. MikaL IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Site-local clarification
Sec 2.5.6 of the site-local addressing architecture states that: Site-Local addresses have the following format: | 111011 | 54 bit subnet ID | 64 bit Interface ID | Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may be up to 54-bits long, it is expected that globally-connected sites will use the same subnet IDs for site-local and global prefixes. Does the interpretation of the above sentence mean, if my global prefix is 3FFE:2900:1107:314::/64, my site-local prefix would be FECE:2900:1107:314::/64 ? Thanks, Siva
RE: a few comments on anycast mechanisms
TCP has the problem that it simply can't be used with an anycast address without changing the protocol or somehow handling the binding transparently on L3 (as in MIPv6). UDP doesn't have this problem; at most the applications need to be changed to react correctly to peer address change. = But is this the only problem? I mean even if there is a way of making apps using UDP react correctly to address changes, is it not possible that some apps would want to make sure that they are still talking to the _same_peer_ and not just the same application on another host? Some of the problems relate to figuring out what constitutes a session with a UDP application. = There was a reference made that the draft deals with stateful applications. Hesham IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: a few comments on anycast mechanisms
On Tue, 2003-02-25 at 23:20, Hesham Soliman (EAB) wrote: = Right, but I guess the latter type of application would not be harmed by the extra security. Performance? MikaL IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: a few comments on anycast mechanisms
On Tue, 2003-02-25 at 23:20, Hesham Soliman (EAB) wrote: = Right, but I guess the latter type of application would not be harmed by the extra security. Performance? = In theory yes, but I don't know how significant it will be. I suppose we need to see a complete framework/solution before we can discuss the scenarios where performance will be a factor and how significant it will be. Hesham MikaL IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Site-local clarification
Siva Veerepalli wrote: | [ARCH] Site-local addresses are designed to be used for | addressing inside of a site without the need for a global | prefix. Although a subnet ID may be up to 54-bits long, | it is expected that globally-connected sites will use the | same subnet IDs for site-local and global prefixes. Does the interpretation of the above sentence mean, if my global prefix is 3FFE:2900:1107:314::/64, my site-local prefix would be FECE:2900:1107:314::/64 ? No. Following the recommendations of RFC3177, if your global prefix is 3FFE:2900:1107:314::/64 and the same subnet also has a site-local address the site-local prefix would be FEC0:0:0:314::/64. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Follow up to IAB response to Robert Elz's Appeal
The IAB has responded to an appeal from Robert Elz of the IESG decision to approve the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document should not be published as a Draft Standard [1]. Given that the revised document is a significant improvement over RFC 2473, and that RFC2473 is badly out of date, we believe it is desirable to go ahead and publish the document as a Proposed Standard at this time ASAP in order to get a replacement to RFC2473 out. In parallel, it would be appropriate to discuss the details of the IAB response and how the WG wishes to respond to the IAB recommendations. Note that approving the document as PS at this time does not imply that the WG agrees with all of the IAB's recommendations nor does it preclude any particular follow-on action by the WG or IESG. However, approval at PS is something that can be done relatively quickly. Does this approach make sense to the WG? Bob Hinden, Margaret Wasserman; IPv6 Chairs Thomas Narten, Erik Nordmark; Internet ADs [1] IAB, Re: Appeal against IESG decision, http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Follow up to IAB response to Robert Elz's Appeal
Bob, Sounds like a good approach. Hesham -Original Message- From: Bob Hinden [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 1:01 AM To: [EMAIL PROTECTED] Subject: Follow up to IAB response to Robert Elz's Appeal The IAB has responded to an appeal from Robert Elz of the IESG decision to approve the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document should not be published as a Draft Standard [1]. Given that the revised document is a significant improvement over RFC 2473, and that RFC2473 is badly out of date, we believe it is desirable to go ahead and publish the document as a Proposed Standard at this time ASAP in order to get a replacement to RFC2473 out. In parallel, it would be appropriate to discuss the details of the IAB response and how the WG wishes to respond to the IAB recommendations. Note that approving the document as PS at this time does not imply that the WG agrees with all of the IAB's recommendations nor does it preclude any particular follow-on action by the WG or IESG. However, approval at PS is something that can be done relatively quickly. Does this approach make sense to the WG? Bob Hinden, Margaret Wasserman; IPv6 Chairs Thomas Narten, Erik Nordmark; Internet ADs [1] IAB, Re: Appeal against IESG decision, http://www.iab.org/Appeals/kre-ipng-address-arch-draft-stand ard-response.html IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Follow up to IAB response to Robert Elz's Appeal
Bob Hinden wrote: The IAB has responded to an appeal from Robert Elz of the IESG decision to approve the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document should not be published as a Draft Standard [1]. Given that the revised document is a significant improvement over RFC 2473, and that RFC2473 is badly out of date, we believe it is desirable to go ahead and publish the document as a Proposed Standard at this time ASAP in order to get a replacement to RFC2473 out. In parallel, it would be appropriate to discuss the details of the IAB response and how the WG wishes to respond to the IAB recommendations. Note that approving the document as PS at this time does not imply that the WG agrees with all of the IAB's recommendations nor does it preclude any particular follow-on action by the WG or IESG. However, approval at PS is something that can be done relatively quickly. Does this approach make sense to the WG? sounds to me like a sensible course of action. - Alain. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Follow up to IAB response to Robert Elz's Appeal
Bob Hinden wrote: The IAB has responded to an appeal from Robert Elz of the IESG decision to approve the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document should not be published as a Draft Standard[1]. Given that the revised document is a significant improvement over RFC 2473, and that RFC2473 is badly out of date, Agree. we believe it is desirable to go ahead and publish the document as a Proposed Standard at this time ASAP in order to get a replacement to RFC2473 out. In parallel, it would be appropriate to discuss the details of the IAB response and how the WG wishes to respond to the IAB recommendations. Note that approving the document as PS at this time does not imply that the WG agrees with all of the IAB's recommendations nor does it preclude any particular follow-on action by the WG or IESG. However, approval at PS is something that can be done relatively quickly. Does this approach make sense to the WG? Does to me. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pekka Savola Sent: Tuesday, February 25, 2003 12:00 PM To: Vijayabhaskar A K Cc: 'Ralph Droms'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt On Mon, 24 Feb 2003, Vijayabhaskar A K wrote: That is, the requesting router is in charge of all the prefixes until they expire. The robust requesting router implementation will perform some sane refreshing of these bindings way before they expire, even periodically. Thus, I fail to see any reason why these values would have to be communicated from the delegator. Yes, I agree that the it can refresh the bindings at any periodic intervals it want. But, what if the delegating router is dead and not responding at all? Then it will try again a bit later and succeed. The time bit later is well defined by DHCPv6 base architecture. Hence, dhcpv6 provides you with two values: T1 - This is the time at which the requesting router starts contacting the delegating router for the renewal of the lease... T2 - If till the expiration of T2 it didn't get the response from the delegating router, it can contact any available dhcpv6 server to refresh its bindings. Do you mean that similar T1 T2 values are being used by DHCP base spec? In that case I guess it's ok, but otherwise, I still fail to see the usability. Yes, T1 and T2 values are being used in DHCPv6 base spec. Ofcourse, the requesting router can generate these values itself. With DHCPv6 server sending T1 and T2 values, the requesting router dont need to recalculate the values again and again.. Trust the DHCPv6 server, the values provided by it makes the requesting router to refresh its bindings well before the expiry.. Well, typically the conventional wisdom is *not* to trust any external parties to any extent greater than necessary :-) If you are able to trust the prefixes given by DHCPv6, then there will be no harm in trusting the time values provided by it :-) Prefix delegation by DHCP is not meant to be all-purpose-zero-configuration tool for routers, I think. This seems conflicting -- a fringe case which should not came up. Better would be just require that the requesting router will get a delegation from all the ISP's for itself, and subnet accordingly. If the following does not apply, it seems to me that there must be routers connected to the downstreaming interfaces -- which in turn could perform prefix delegation directly from the ISP, the first router acting as a relay. Doesn't seem to be need for this.. Need not be. Simple case is Home networks, they dont afford to have individual routers for every ISPs. They may need multiple ISPs for high availablity or some other reason. In this case, there will be only one border router with mutiple appliances/nodes in the downstreaming interfaces, which may span in one or more links. In this case, it needs to unique IA_PD for every ISP. Seems a bit far-fetched, IMO, but ok.. Regardless of that, I'm not sure how the requesting router would discover more of these delegating routers -- how would they be connected? Which kind of infrastructure would typically be between requesting router and multiple delegating routers? I beleive there will be unique dialup connection with each ISPs. .. as above, I've yet to see dial-up routers deployed which would have two dial-out adapters and phone jacks, but ok.. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ dhcwg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dhcwg IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: Ofcourse, the requesting router can generate these values itself. With DHCPv6 server sending T1 and T2 values, the requesting router dont need to recalculate the values again and again.. Trust the DHCPv6 server, the values provided by it makes the requesting router to refresh its bindings well before the expiry.. Well, typically the conventional wisdom is *not* to trust any external parties to any extent greater than necessary :-) If you are able to trust the prefixes given by DHCPv6, then there will be no harm in trusting the time values provided by it :-) It's not about that kind of trust -- rather I trust that the times provided to me by the operator are the best possible choices, and they have in fact provided them -- I'd imagine you trust your own DHCPv6 implementation and configuration more than your ISP's. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pekka Savola Sent: Tuesday, February 25, 2003 12:19 PM To: Ralph Droms Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Similar discussion has already been had, so I'll try to keep it at the minimum. On Mon, 24 Feb 2003, Ralph Droms wrote: At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: On Tue, 11 Feb 2003, Ralph Droms wrote: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a delegating router (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a requesting router (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt- prefix-delegation-02.txt A few comments. Bigger issues -- I'm sorry for bringing them up so late (relatively), but I haven't really thought/read about the big picture, before. 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be mostly redundant -- the requesting router should just take the minimum of lifetimes of the prefixes, calculate it in the same fashion, that's it. Of course, there is an assumption (which doesn't seem to be properly addressed!) that the requesting router is free to refresh the delegation when it feels right, even every hour, day, month etc. without regard to the lifetimes -- indeed, I think *NO* implementation would just wait until the last minute to refresh them. Is there something I'm missing? The spec allows for flexibility in deployment scenarios by allowing the ISP (through the delegating router) to control the behavior of the requesting router, or by leaving the behavior under the control of the requesting router by setting T1 and T2 to 0 (see section 8 of the draft). Yes, I noticed they can be zero -- all I'm questioning is the usability of this flexibility. I fail to see why such flexibility is useful. The requesting router can be as flexible as it wants -- and refresh bindings when it deems it necessary even without guidance. On reading your previous mail, i thought you have agreed with T1 and T2 :-) Probably, the routers which are wise enough to rely up of prefixes provided by the DHCPv6 server and dumb enough to trust the time values provided by it, may need this ;-) Perhaps, these T1 and T2 values exist from DHCPv4 architecture itself and worked successfully. If the requesting routers doesn't want to trust the time values, they can just ignore the T1 and T2 values and refresh the leases whenever it wishes. 2) Multiple IA_PD looks unnecessarily complex. Are there any valid reasons why it wouldn't be just enough to have only one IA_PD per requesting router? (The option to and subsequent complexity of) generating one for each interface seems like a completely unnecessary feature to me -- it's the router which should be doing prefix delegation to it's downstream interfaces! The only feature I can quickly think of which could profit from this is kind of shared routers where the connected interfaces are separate administrative entities with differently configured properties at the ISP. This seems questionable to me, a case for manual configuration or advanced prefix delegation to me. So, I think the possibility to do prefix delegation in more complex ways than really necessary should be seriously considered. Keep it Simple, Stupid would be a good rule. There is no requirement that the delegating router supply more than one IA_PD to the requesting router, and limiting the delegation to only one IA_PD seems overly restrictive. For example, a delegating router might send one IA_PD for each ISP used by a customer site. I don't see it overly restrictive myself: as an operator and end-user, if someone connects to two ISP's, it's (almost, at least) always done either from two separate routers (no use doing it from one, really), or in a serial fashion (terminate one, establish the other -- like dialup). Simultaneous connection is also needed in some cases, as i told earlier, like, high availablity It is not the intention of the draft that the requesting router receive one IA_PD for each of its downstream interfaces. If that is your understanding of the draft, then we need to clarify the text. In section 11.1, the draft specifies that the requesting router assigns subnets from the delegated prefixes to each of its downstream interfaces. I understood well that the particular behaviour is only optional, but the problem seems to be that the main behaviour is described quickly (indeed, it's rather simple) and then the spec goes on at great length describing the fringe cases. This makes an unwary reader think the fringe cases are actually more than just
Re: Follow up to IAB response to Robert Elz's Appeal
This approach is ok to me. Regards, Jordi - Original Message - From: Bob Hinden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 8:01 AM Subject: Follow up to IAB response to Robert Elz's Appeal The IAB has responded to an appeal from Robert Elz of the IESG decision to approve the IPv6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document should not be published as a Draft Standard [1]. Given that the revised document is a significant improvement over RFC 2473, and that RFC2473 is badly out of date, we believe it is desirable to go ahead and publish the document as a Proposed Standard at this time ASAP in order to get a replacement to RFC2473 out. In parallel, it would be appropriate to discuss the details of the IAB response and how the WG wishes to respond to the IAB recommendations. Note that approving the document as PS at this time does not imply that the WG agrees with all of the IAB's recommendations nor does it preclude any particular follow-on action by the WG or IESG. However, approval at PS is something that can be done relatively quickly. Does this approach make sense to the WG? Bob Hinden, Margaret Wasserman; IPv6 Chairs Thomas Narten, Erik Nordmark; Internet ADs [1] IAB, Re: Appeal against IESG decision, http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] * Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
On Wed, 26 Feb 2003, Ole Troan wrote: 2) Multiple IA_PD looks unnecessarily complex. Are there any valid reasons why it wouldn't be just enough to have only one IA_PD per requesting router? (The option to and subsequent complexity of) generating one for each interface seems like a completely unnecessary feature to me -- it's the router which should be doing prefix delegation to it's downstream interfaces! let me pick this one up from the start. the reasons for allowing multiple IA_PDs are: - consistency with address assignment as you can use multiple IA_NAs - future-proofing. in the ISP/user scenario I do see little need for multiple IA_PDs. if PD is used within an administrative domain assigning prefixes to downstream interfaces may make more sense My take on this is is that we don't need that yet, so why add it yet; leaving the base prefix delegation spec extendable (e.g. define multiple IA_PD's in a later document) would be just fine. it does add some complexity, and I think we've made it pretty clear in the draft that the typical usage will be to use one IA_PD. we just didn't want to close the door on possible future uses of the protocol. IMO, it wasn't as clear as that. I can live with this, but I can't help wondering why the base spec has to cover even all the theoretical cases. I'd much rather see a very simple basic version of prefix delegation which can be used to get started. There's no way we could anticipate what will be needed in 3-5 years and we could further define the extensions when they're needed. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: The spec allows for flexibility in deployment scenarios by allowing the ISP (through the delegating router) to control the behavior of the requesting router, or by leaving the behavior under the control of the requesting router by setting T1 and T2 to 0 (see section 8 of the draft). Yes, I noticed they can be zero -- all I'm questioning is the usability of this flexibility. I fail to see why such flexibility is useful. The requesting router can be as flexible as it wants -- and refresh bindings when it deems it necessary even without guidance. On reading your previous mail, i thought you have agreed with T1 and T2 :-) Well, if it's DHCPv6 functionality, it's ok to keep some of those intact even if misguided.. :-) Probably, the routers which are wise enough to rely up of prefixes provided by the DHCPv6 server and dumb enough to trust the time values provided by it, may need this ;-) Perhaps, these T1 and T2 values exist from DHCPv4 architecture itself and worked successfully. Well, the routers MUST have this code *anyway*, as they cannot be sure T1/T2 will always be provided, so I really see little use.. I don't see it overly restrictive myself: as an operator and end-user, if someone connects to two ISP's, it's (almost, at least) always done either from two separate routers (no use doing it from one, really), or in a serial fashion (terminate one, establish the other -- like dialup). Simultaneous connection is also needed in some cases, as i told earlier, like, high availablity High availability to two ISP's from one router is a joke. Certainly. I see this as a potential problem from two directions: 1) delegating router handling untrusted input values, creating delegations based on them, and 2) the requesting router requesting something that architectually differs *a lot* from what's given (example: /64's directly for its interfaces, and one /48 delegated). The same problem will occur, when the requesting router is expecting the /48 and the server ignoring its preference and just gives it /64. Sure. (Or the same for different changes in prefix lengths.) The solution would be, 1) when a site registers with ISP, preconfigure the topology of the site in the dhcpv6 server. Thus, it can provide the requesting router with necessary prefixes. I think it is natural to be able to expect that the ISP configures this kind of stuff (one /64, multiple /64, /48 -- that's all they need!) out-of-band. As currently. I don't think there's any reason to expect otherwise. 2) If the site topology is not known, configure dhcpv6 server with some dynamic pool which always provide a single /64 prefix for the IA_PD. Let the requesting router send as many as IA_PD it wants. But, here the concept of subnetting dies. Very discourageable, IMO. Basically, the site which is connecting to ISP is authenticated, moreover, they pay for whatever service they use, i dont see that any harm in taking the preference from the requesting router and assign the prefix accordingly. You fail to understand the relationship between the ISP and the user. Whether they use /64, /48 or whatever is, and will typically be, pre-agreed when people sign up for the service. Communicated out-of-band. I don't think that typically the user is able to affect that decision (at prefix delegation time) at all. Of course, ISP's could change their models, but don't count on it.. Then what? Can the requesting router handle this kind of situation? The problem is that entering preferences *in-band* (instead of out-of-band, as usual) seems problematic, as it creates difficult situations at both ends in the cases the preferences are not met (and policy decisions even if met). At the very least, one should clarify something along the lines of In any case, the requesting router MUST NOT depend on any of its preferences to be honored if this feature is really necessary. I pay for my using the services provided by ISPs, why shouldn't my preferences be honoured? ISP's will love you for spending 50$/mo for the premium service instead of 30$/mo, so -- maybe they'll let you say the preference. For the rest, it won't matter and it's configured out-of-band. Most agreements with ISP's are very draconian. The problems like these are not solved with specifications. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
On Sat, Feb 22, 2003 at 12:48:27PM +0200, Mika Liljeberg wrote: Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format if necessary. Just add some text explaining this. With our hybrid IPv4/IPv6 stack implementation this would work out of the box. Did I miss some announcement that mapped addresses were suddenly allowed to be present on the wire? They were supposed to be only used in the socket API. Camels... tents -- David Terrell | War is peace, Prime Minister, Nebcorp | freedom is slavery, [EMAIL PROTECTED] | ignorance is strength http://wwn.nebcorp.com/ | Dishes are clean. - Chris Fester IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
