Re-, Please see inline.
Cheers, Med -----Message d'origine----- De : Rémi Després [mailto:[email protected]] Envoyé : lundi 9 mai 2011 14:42 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution Med, Thank you for the quick reaction. More in line. Le 9 mai 2011 à 13:38, <[email protected]> a écrit : > Hi Rémi, > > Thank you for the comments. > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Rémi Després [mailto:[email protected]] > Envoyé : lundi 9 mai 2011 11:10 > À : Satoru Matsushima; BOUCADAIR Mohamed OLNC/NAD/TIP; Yiu Lee; Olaf Bonness; > Isabel Borges > Cc : Softwires-wg > Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution > > Satoru-san, Med, all authors, > > Congratulation for this important I-D, and for the quick convergence among > all of you. > > Here are, after a detailed review, some remarks: > > 1. Sec 2 - Terminology (and some other instances of "port range") > > "Port space", as used in sec. 5.3, or "port set", would be more appropriate > than "port range" in a motivation document because: > - A port range is a particular case of port set or port space, but not the > reverse. > - At least one documented solution uses port sets that contain several port > ranges. > > Med: I don't see much the difference between a port range and a port set. A range is between two limits. A set of ports defined by several non-overlapping prefixes cannot therefore be called a range. > IMO, what is important is to use consistent terminology in the document. Same view. > Do you have any pointer (other that the solution document you are referring > to) where "port set" is defined? Not that I know, but a port set is self explanatory (nothing more than a set of ports). > If needed, I can update the text to state that both "port range" and "port > set" are used interchangeably. New suggestion, hopefully better: replace, throughout the document, "port range" by "port range or port set". Med: For the sake of easing the readability of the document, I added "Within this document "port set" and "port range" are used interchangeably." instead of repeating each time both terms. > 2. Sec 3. IPv4 Service Use case > > While the "Host based model is out of scope", it would be IMHO good to note > that: > "The model can however apply to any host that includes a CPE function". > > Med: I prefer having the explicit statement to say the host-based model is > out of scope. Same view. The intended proposal wasn't to delete this sentence (sorry if it wasn't clear enough). It is just to add the new sentence after it. Med: One can consider a host embedding a CPE function as a router, no? > 5.1. Dependency Between IPv4 and IPv6 Address Assignments > > The I-D says "Providing two IPv6 prefixes avoids the complexity related to > the adaptation of the IPv6 addressing scheme to the IPv4 addressing scheme". > But some solutions don't require to adapt the IPv6 addressing scheme to that > of IPv4. > (A particular example is described in sec 3.2 of > draft-despres-softwire-sam-01. With it, several IPv4 prefixes are supported > without any impact on the IPv6 addressing scheme) > Suggestion: after "complexity", add "that may be". > > Med: Done. Thanks. > FWIW, I also updated that section with a comment received from R. Maglione: > > "For Service Providers requiring to apply specific policies on per > Address-Family (e.g., IPv4, IPv6), some provisioning tools (e.g., DHCPv6 > option) may be required to derive in a deterministic way the IPv6 address to > be used for the IPv4 traffic based on the IPv6 prefix delegated to the home > network. " > > > 5.3. Port Randomization > > The I-D says "Other means than the (IPv4) source port randomization to > provide protection against attacks should be used (e.g., use > [I-D.vixie-dnsext-dns0x20] to protect against DNS attacks, [RFC5961] to > improve the robustness of TCP against Blind In-Window Attacks)". > > However: > - The solution cited as example is from an expired I-D. > - Another solution is that the DNS server of the operator be accessible in > IPv6, and that the CPE translates IPv4 DNS queries to send them to this > server. In this case, no port-set restriction applies. > Suggestion: > - Delete the paragraph, or, > - Note that IPv6 DNS servers is a solution (and avoid the reference to > I-D.vixie-dnsext-dns0x20). > > Med: I updated the text to mention that using IPv6 is one of the solutions. Thanks. > I think this I-D should become asap a WG draft. > (This would preferably be with some improvements like those proposed above, > but this isn't IMHO a prerequisite.) > > The sooner it reaches RFC status, the better. > > Regards, > RD > > > > > > > Le 6 mai 2011 à 12:39, Satoru Matsushima a écrit : > >> Dear colleague, >> >> We've uploaded an I-D to express our motivation of stateless IPv4 over IPv6 >> as an IPv6 transition solution. Since the outcome of recharter session in >> last softwires wg meeting, ADs required the motivation draft to standardize >> stateless v4 over v6 solution at IETF. >> >> We, authors of the draft, have been trying to clearly explain our >> motivation, scope, and current open questions for stateless solution as much >> as possible in this draft. We believe that it should be helpful to >> understand what our motivation is. >> >> Please find it out from following url: >> http://www.ietf.org/id/draft-operators-softwire-stateless-4v6-motivation-00.txt >> >> We'd like to have your kind review, and comments, also welcome to discuss >> about the motivation in the softwires mailing list. >> >> Best regards, >> --satoru >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
