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 <[email protected]> On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, June 13, 2018 12:46 PM
To: [email protected]; [email protected]; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to