Subject: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 12:35:31 +0200

Forgot something to make it clearer ...

Even if a reference to RFC5569 (6rd) as per Barbara comment, may be sufficient, 6RD is referencing to 6to4 which in turn is using an outdated reference to 6in4. I think this is a *possible* path, however my suggestion of using a direct reference to 6in4 is *only* for the sake of clarity and simplicity to anyone reading the document.

*no* further requirements implied doing a “direct” reference to the source of the encapsulation protocol (protocol 41).

RFC7059 discusses all those mechanisms and may provide also some light. My reading of that document, again, confirms that there is no difference from the perspective of the CE perspective. The CE need to know the end point of the tunnel, and the allocated prefix, same for all the 3 (6rd, 6to4, 6in4).

Regards,
Jordi

-----Mensaje original-----
De: JORDI PALET MARTINEZ <[email-masked]>
Fecha: jueves, 13 de abril de 2017, 12:04
Para: "[email-masked]" <[email-masked]>
Asunto: draft-ietf-v6ops-rfc7084-bis-01

    (changed subject to focus in the actual version and discussion)
    
    Hi Barbara,
    
    I see your point and I understand it, but I’ve done the following to make sure that there is no discrepancy.
    
    1) I’ve re-read with a lot of care RFC5569 (6rd), RFC3056 (6to4), RFC2893 and RFC4213.
    2) I’ve also searched for MAY, SHOULD, MUST, etc., and other “picky” text in those documents.
    3) I’ve concluded that there is nothing that any of those documents is requiring that is not already part of the 6rd requirements.
    
    It will be nice if someone else can reassess that, so is not just me …
    
    If that’s the case, and even more, considering that the complete section is a MAY, I don’t see how this will conflict with your actual RFQs, etc.?
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: "STARK, BARBARA H" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: miércoles, 12 de abril de 2017, 21:20
    Para: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

        > RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is referring
        > to RFC2893 (6in4, protocol 41), which has been updated by RFC4213.
        > 
        > We are talking about the same.
        > 
        > If you have a 6to4 router at home, you can just try. Create a HE tunnel
        > broker, and input manually the parameters even if your router only shows a
        > 6rd in the GUI. It works. Believe me.
        
        What I think I hear you saying is:
        If a CE router implements RFC 5569, then the access network can use the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel.
        
        If this is correct, then what I'm saying is I will not support a requirement that dictates I and my CE router vendors (who implement 6rd) MUST look at or read  or scour RFC 4213 to see if there is some additional requirement that RFC 4213 introduces, because they are now required to be compliant with it. The reference to RFC 5569 SHALL be sufficient to direct implementation of the functionality, with no reference to RFC 4213.
        UI requirements are out of scope.
        Barbara

**********************************************
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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: [email-masked]
Date: Thu, 13 Apr 2017 12:39:15 +0200

Jordi,

> RFC7059 discusses all those mechanisms and may provide also some light. My reading of that document, again, confirms that there is no difference from the perspective of the CE perspective. The CE n…

No. 6rd and 6to4 are mesh. 6in4 is p2p.
6in4 uses DHCPv6 PD like any other link layer.
The IETF have defined no mechanism to provision 6in4 tunnels.

I suggest you think through the deployment model of this before you continue the argument.

Cheers,
Ole

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops