Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

[JORDI PALET MARTINEZ <[e-mail]>]

Hi all,

We just submitted a new version, which I think address all the discuss and comments (some of them were clarifications that were provided by email responses to the IESG).

This included removing the reference to RFC8115 as a DHCP method to obtain the NAT64 prefix.

That means that this can only be done by PCP/RFC7225 (if available) or RFC7050.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?include_text=1

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <[e-mail]> en nombre de Ole Troan <[e-mail]>
Fecha: miércoles, 9 de enero de 2019, 11:22
Para: Lorenzo Colitti <lorenzo=[e-mail]>
CC: "[e-mail] WG" <[e-mail]>, <[e-mail]>, <[e-mail]>, The IESG <[e-mail]>, JORDI PALET MARTINEZ <jordi.palet=[e-mail]>, Suresh Krishnan <[e-mail]>
Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

    > It *is* contradicting the standard. The standard says that the uPrefix64 is "to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain". This document says that it should be used as a unicast NAT64 prefix.
    
    I must agree with Lorenzo here.
    This is not the right document to specify a new NAT64 prefix discovery mechanism.
    
    Ole
    
    
    > 
    > On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ <jordi.palet=[e-mail]> wrote:
    > Hi Lorenzo,
    > 
    >  
    > 
    > Yes, I recall that very well. The only objections where from you and from David.
    > 
    >  
    > 
    > We are using a format that is not defined in RFC8115 for something else. It is a trick, right, but is not contradicting neither changing any standard, because the configuration of the two zeroed fields.
    > 
    > 
    > Regards,
    > 
    > Jordi
    > 
    >  
    > 
    >  
    > 
    >  
    > 
    > De: v6ops <[e-mail]> en nombre de Lorenzo Colitti <lorenzo=[e-mail]>
    > Fecha: miércoles, 9 de enero de 2019, 10:55
    > Para: JORDI PALET MARTINEZ <jordi.palet=[e-mail]>
    > CC: "[e-mail] WG" <[e-mail]>, <[e-mail]>, <[e-mail]>, Suresh Krishnan <[e-mail]>, The IESG <[e-mail]>
    > Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)
    > 
    >  
    > 
    > On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ <jordi.palet=[e-mail]> wrote:
    > 
    > So, in summary, implementing or not multicast support, is not related to the implementation of RFC8115 (just a simple DHCPv6 option) which is used here for discovering the NAT64 prefix and allowing the prioritization of the transition mechanisms, avoiding updating other IETF documents and waiting for the IETF to approve a new standard DHCPv6 option specific for the NAT64.
    > 
    >  
    > 
    > Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to specify the NAT64 prefix is that there was no consensus to define a way to provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you presenting such an option a few IETFs ago and receiving pretty negative opinions on it from the mike line.) If that's the case, then it's not appropriate to ignore that lack of consensus and essentially define such an option anyway.
    > 
    >  
    > 
    > It's not even clear to me how an informational document (which this is) can take RFC 8115 (which is a standards track document) and redefine the uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix64 as not representing standard unicast addresses:
    > 
    >  
    > 
    >    uPrefix64:  this field identifies the IPv6 unicast prefix to be used
    > 
    >       in SSM mode for constructing the IPv4-embedded IPv6 addresses
    > 
    >       representing the IPv4 multicast sources in the IPv6 domain.
    > 
    >  
    > 
    > Standards track documents have precedence over informational documents, right? If so, then even if this informational document is published as is, the text will effectively be a no-op because it contradicts RFC 8115.
    > 
    > _______________________________________________ v6ops mailing list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
    > 
    > 
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > 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.
    > 
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.