Re: [Softwires] [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas
Hi Bernie, Thanks a lot for looking at this. I may be wrong, but I think they are different "option codes" tables and should not be a conflict. If I'm wrong it means the RFC8026 table it's just a subset, which is confusing when you look into the IANA web page, because looks like different tables ... I was looking at https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml There is a specific table for RFC8026 option codes: Option Code S46 Mechanism Reference 64 DS-Lite [RFC6334] 88 DHCPv4 over DHCPv6 [RFC7341] 94 MAP-E [RFC7598] 95 MAP-T [RFC7598] 96 Lightweight 4over6 [RFC7598] This table right now is matching the RFC8026, as no other option codes have been added after. Those option codes (64, 88, etc.), also match other DHCPv6 option codes, in the main table. In some cases, is very clear it has the same meaning, but in others I'm not sure ... But of course, this is a minor detail, and as you say it looks like 46 (OPTION_CLT_TIME) is something never will have a conflict with RFC8026, so we can explicitly say that, or we can just ask IANA to assign whatever is the most convenient one. I'm fine either way. Thanks! Regards, Jordi -Mensaje original- De: v6ops en nombre de "Bernie Volz (volz)" Fecha: miércoles, 13 de junio de 2018, 23:02 Para: JORDI PALET MARTINEZ , "dh...@ietf.org" , "softwires@ietf.org" , "v6...@ietf.org" Asunto: Re: [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Hi Jordi: Haven't look at the draft in detail yet, but I did find it rather odd that you are using option code 46. As these are DHCPv6 option codes, this maps to: Value Description Client ORO Singleton Option Reference 46 OPTION_CLT_TIME No Yes [RFC5007] I understand that you may have picked this simply because it is a nice number for v4/v6 transition mechanisms. But it seems like a rather odd mapping. If you really think this is a wise thing to do, you should at least document that you are requesting this because of its value (and because it would never "really" be used for RFC 8026) - not that this OPTION_CLT_TIME option itself has any meaning. It may be better to request that IANA assign a DHCPv6 option for this purpose - which should otherwise never be requested by a client (or configured on a server). - Bernie -Original Message- From: dhcwg On Behalf Of JORDI PALET MARTINEZ Sent: Wednesday, June 13, 2018 12:46 PM To: dh...@ietf.org; softwires@ietf.org; v6...@ietf.org Subject: [dhcwg] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Hi all, I'm sending this to Sotfwires and DHC WGs, in order to let know and seek review, but please keep the discussion only in v6ops which is responsible of this document https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Here is the short summary of the reasons for the update. In order to prioritize the different IPv4-as-a-Service (in IPv6-only networks) transition mechanisms (so the ISP can "agree" with each CPE which one to use or even if none), we are using RFC8026 (in short "a DHCPv6-Based Prioritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwires, but it is a DHCPv6 based mechanism. The interesting issue is that because 464XLAT don't have an option code in RFC8026, it can't be ranked the same way, and ideally it should be, as we use also that in order to facilitate the operator to "manage" each transition mechanism status to be on/off (even to different customers). So, what we do with this update, is adding that option code for 464XLAT to the existing ones and instruct IANA about that. If you want to understand the suggested updated and how our algorithm works, you can read directly section 3.3, 7 and 10. Of course, inputs on the complete document are welcome! Thanks! Regards, Jordi ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any
Re: [Softwires] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas
Hi Jordi: Haven't look at the draft in detail yet, but I did find it rather odd that you are using option code 46. As these are DHCPv6 option codes, this maps to: Value Description Client ORO Singleton Option Reference 46 OPTION_CLT_TIME No Yes [RFC5007] I understand that you may have picked this simply because it is a nice number for v4/v6 transition mechanisms. But it seems like a rather odd mapping. If you really think this is a wise thing to do, you should at least document that you are requesting this because of its value (and because it would never "really" be used for RFC 8026) - not that this OPTION_CLT_TIME option itself has any meaning. It may be better to request that IANA assign a DHCPv6 option for this purpose - which should otherwise never be requested by a client (or configured on a server). - Bernie -Original Message- From: dhcwg On Behalf Of JORDI PALET MARTINEZ Sent: Wednesday, June 13, 2018 12:46 PM To: dh...@ietf.org; softwires@ietf.org; v6...@ietf.org Subject: [dhcwg] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Hi all, I'm sending this to Sotfwires and DHC WGs, in order to let know and seek review, but please keep the discussion only in v6ops which is responsible of this document https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Here is the short summary of the reasons for the update. In order to prioritize the different IPv4-as-a-Service (in IPv6-only networks) transition mechanisms (so the ISP can "agree" with each CPE which one to use or even if none), we are using RFC8026 (in short "a DHCPv6-Based Prioritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwires, but it is a DHCPv6 based mechanism. The interesting issue is that because 464XLAT don't have an option code in RFC8026, it can't be ranked the same way, and ideally it should be, as we use also that in order to facilitate the operator to "manage" each transition mechanism status to be on/off (even to different customers). So, what we do with this update, is adding that option code for 464XLAT to the existing ones and instruct IANA about that. If you want to understand the suggested updated and how our algorithm works, you can read directly section 3.3, 7 and 10. Of course, inputs on the complete document are welcome! Thanks! Regards, Jordi ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ___ dhcwg mailing list dh...@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas
Hi all, I'm sending this to Sotfwires and DHC WGs, in order to let know and seek review, but please keep the discussion only in v6ops which is responsible of this document https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Here is the short summary of the reasons for the update. In order to prioritize the different IPv4-as-a-Service (in IPv6-only networks) transition mechanisms (so the ISP can "agree" with each CPE which one to use or even if none), we are using RFC8026 (in short "a DHCPv6-Based Prioritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwires, but it is a DHCPv6 based mechanism. The interesting issue is that because 464XLAT don't have an option code in RFC8026, it can't be ranked the same way, and ideally it should be, as we use also that in order to facilitate the operator to "manage" each transition mechanism status to be on/off (even to different customers). So, what we do with this update, is adding that option code for 464XLAT to the existing ones and instruct IANA about that. If you want to understand the suggested updated and how our algorithm works, you can read directly section 3.3, 7 and 10. Of course, inputs on the complete document are welcome! Thanks! Regards, Jordi ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018
This email announces a Softwire Working Group Last Call (WGLC) on: Since both chairs of softwire WG are the co-authors of this document. I am now acting as the document shepherd for this draft. YANG Modules for IPv4-in-IPv6 Address plus Port Softwires draft-ietf-softwire-yang-04 https://tools.ietf.org/html/draft-ietf-softwire-yang-04 This draft is intended to become a Standard Track RFC. This WGLC will run through the end of the day on Wednesday, June 27, 2018. Comments should be sent to the softwires@ietf.org list, although purely editorial comments may be sent directly to the author. No IPR disclosures have been submitted directly on draft-ietf-softwire-yang-04 Regards and thanks, Sheng Jiang (document shepherd) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Further draft-ietf-softwire-mesh-multicast
Hi Authors, I’m currently in the process of doing the write up for the draft. Please can you tell me if there are there any implementations in existence? Also, I have run v21 through ID-Nits. The important output is below. For the downref, to RFC4925, does this need to be a normative reference? Please can you address these points and submit an updated version. Thanks, Ian Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4291' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC7371' is defined on line 732, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4925 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
