Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

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

Hi Mikael,

No, it is actually much easier than that. The text I proposes will go to the same section (6in4). So, it will be (for the sake of clarity):

5.4.2.  6in4

   6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to
   manually configure IPv6 support via a service provider's IPv4 network
   infrastructure.

   The CE router MAY support 6in4 functionality.  If 6rd is implemented,
   6in4 is already supported as well, as the underlying protocol/technology
   is the same, being the only difference, having the mention of “6in4” in
   the GUI/CLI (just an example) if it is being configured manually, or
   even stating that in the relevant documentation. In other words, no
   additional code is required for the support of 6in4 when 6rd is already
   supported. If 6in4 is supported, it MUST be implemented according to 
   [RFC4213].  The following CE Requirements also apply:

…

No code is required at all, and in any case, the target is MAY, same as we have it right now also for 6rd. Let me explain.

Let’s suppose you have *any* router or OS with 6rd support, never mind the configuration is done by means of DHCP or user-entered configuration (as you said original 6RD-2, but also 6RD-1 and 6RD-3), and instead of a 6RD relay, you provide the 6in4 tunnel-end-point, it just works.

It is simple to understand, because both, 6in4, 6to4, and 6rd, actually do exactly the same encapsulation/decapsulation (protocol-41), and exactly the same routing thing. The difference is that in 6in4 is called a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All the parameters in the UI are the same.

What it means from the perspective of the CE implementer: only a minor text change in the UI. The UI today has a “menu” to allow 6RD-2 config, that says “6rd”. What I’m saying is it to be changed to say “6rd/6in4” or alternatively, one option for “6rd” and another for “6in4”, but actually both choices will bring to the same “code”.

I believe Barbara is worried that if I keep it as a different than 6rd transition mechanism (as it is actually in the current -01 version, see section 5.4.2), because I’m referring to RFC4213, I’m “adding” more requirements behind that RFC. I’m actually reading all those documents and I believe she is wrong on that, but I will answer that in a few minutes.

I see no “technical” difference in having it as part of the 6rd text or as it is right now a separated one, which seems to me (I think you agree on this, if I understood correctly) your email, clearer.

Regards,
Jordi
 

-----Mensaje original-----
De: Mikael Abrahamsson <[e-mail]>
Organización: People's Front Against WWW
Responder a: <[e-mail]>
Fecha: jueves, 13 de abril de 2017, 10:32
Para: JORDI PALET MARTINEZ <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote:
    
    > The CE router MAY support 6in4 functionality.  If 6rd is implemented, 
    > 6in4 is already supported as well, as the underlying protocol/technology 
    > is the same, being the only difference, having the mention of “6in4” in 
    > the GUI/CLI (just an example) if it is being configured manually, or 
    > even stating that in the relevant documentation. In other words, no 
    > additional code is required for the support of 6in4 when 6rd is already 
    > supported
    
    In the original 6RD-2 requirement that talks about user configuration, for 
    configuring 6in4 the UI would need to look slightly different, right? 
    Depending on some choices in UI, some input methods of the parameters 
    might not work with 6in4.
    
    So I guess your intention to include 6in4 could be done either as a new 
    transition protocol with SHOULD, or it can add an additional MAY 
    requirement in 6RD that the settings be compatible for configuring a 
    generic 6in4 tunnel as well. The above text seems to be the latter?
    
    I think it would actually make more sense to create a "new" transition 
    technology in there in that case. That would keep it clean the way I 
    interpret Barbaras intention is?
    
    -- 
    Mikael Abrahamsson    email: [e-mail]



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