Re: I-D Action: draft-ietf-6man-ra-pref64-02.txt

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

Responding to the CE part.

I think, ideally, once this document is approved, we could work in an RFC8585-bis to update that.

Regards,
Jordi
@jordipalet
 
 

El 23/7/19 14:20, "ipv6 en nombre de Jen Linkova" <[e-mail] en nombre de [e-mail]> escribió:

    Hi Martin,
    
    On Wed, Jul 24, 2019 at 2:54 AM Martin Hunek <[e-mail]> wrote:
    > I've also read the document, and I do have a questions:
    > 1) How do you encode suffix of prefixes other then /96?
    
    Ah, good point. The question is: do we need to?
    The existing standard says  the suffix SHOULD be 0.
    
    > 2) How should a Router behave when it receives this option from its upstream?
    >
    > This is actually question I've asked you at IETF 104. When you have an topology in which the operator would send Pref64 option in its RAs and to this link the customer router (CPE) would be connected. Then customer devices would be connected after that router. Should that Pref64 option be transitive trough CPE, so it would get to those devices behind CPE? Or should be non-transitive so it would be only used for traffic generated by router itself? I think that this should be specified by the document.
    
    I do not believe it belongs to this draft. This draft specifies the
    option format, how router sends it in RA and how hosts processes it.
    What you are describing looks like CPE requirements and would belong
    to v6ops. AFAIR we do not specify 'transitiveness' for any other RA
    options. IMHO it should belong to a document which describes how
    routers shall receive configuration from WAN and send it downstream,
    not to the standard track which defines the option format.
    
    > Otherwise I support this idea. But especially question 2 should be addressed in the document or you would solve NAT64 detection only in one segment / on link as it would not work over CPE or in case that user itself would connect two routers after each other (yes, I've seen that, there are such people out there :-) ).
    
    I guess those people configure other RA options on the downstream
    interfaces somehow anyway (PIOs, RDNSS etc) - I'm not sure what's the
    point of propagating Pref64 downstream while PIOs/RDNSS still need to
    come from somewhere else.
    
    > Dne úterý 23. července 2019 15:40:40 CEST, [e-mail] napsal(a):
    > >
    > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
    > > This draft is a work item of the IPv6 Maintenance WG of the IETF.
    > >
    > >         Title           : Discovering PREF64 in Router Advertisements
    > >         Authors         : Lorenzo Colitti
    > >                           Jen Linkova
    > >       Filename        : draft-ietf-6man-ra-pref64-02.txt
    > >       Pages           : 10
    > >       Date            : 2019-07-23
    > >
    > > Abstract:
    > >    This document specifies a Router Advertisement option to communicate
    > >    NAT64 prefixes to clients.
    > >
    > >
    > > The IETF datatracker status page for this draft is:
    > > https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/
    > >
    > > There are also htmlized versions available at:
    > > https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-02
    > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-ra-pref64-02
    > >
    > > A diff from the previous version is available at:
    > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ra-pref64-02
    > >
    > >
    > > Please note that it may take a couple of minutes from the time of submission
    > > until the htmlized version and diff are available at tools.ietf.org.
    > >
    > > Internet-Drafts are also available by anonymous FTP at:
    > > ftp://ftp.ietf.org/internet-drafts/
    > >
    > > --------------------------------------------------------------------
    > > IETF IPv6 working group mailing list
    > > [e-mail]
    > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > > --------------------------------------------------------------------
    > >
    >
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > [e-mail]
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    
    
    
    --
    SY, Jen Linkova aka Furry
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [e-mail]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
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.