Subject: Re: Current status of IPv6 support?

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 04 Jan 2000 10:52:49 +0100

Thomas,

At 17:47 21/12/1999 +0100, Thomas Wolfram wrote:

<clip>

>But other drafts seem to make few provisions for IPv6 if at
>all (ldp, icmp, diff-ext). 

We will add a statement in the next rev of the diff-ext I-D that it is
applicable to both IPv4 and IPv6.

<clip>

>And what about the extended RSVP? It supports IPv6 prefixes
>but tunnel sender and end point addresses as well as Extended
>Tunnel IDs are defined using IPv4 addresses. So IPv6 could be
>transmiited over a ER-LSP but the LERs/LSRs themselves would
>still have to run IPv4, right?
>

as per <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt>:
"The LABEL_REQUEST object
   indicates that a label binding for this path is requested and also
   provides an indication of the network layer protocol that is to be
   carried over this path. The reason for this is that the network layer
   protocol sent down an LSP cannot be assumed to be IPv4 and cannot be
   deduced from the L2 header, which simply identifies the higher layer
   protocol as MPLS."

and :
"Label Request without Label Range
      class = 19, C_Type = 1  (need to get an official class num from
                               the IANA)
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |             L3PID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

So, I'd say it is possible to set up LSP Tunnels via the currently defined
RSVP extensions to transport IPv6.

Francois

>Thanks in advance,
>-- 
NOTE : New Mobile Number        +33 6 89 10 81 59
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Phone Office:   +33 4 92 96 75 64
Phone Home Office:      +33 4 92 94 00 78
Mobile :                +33 6 89 10 81 59
Vmail:                  +33 1 69 18 62 66
Fax:                    +33 4 92 96 79 08
Email:          [email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: "Thomas Wolfram" <[email-masked]>
Date: Thu, 6 Jan 2000 03:29:35 +0100

Francois,

> At 17:47 21/12/1999 +0100, Thomas Wolfram wrote:
...
> applicable to both IPv4 and IPv6.

that would be fine. I think it would be quite useful if all MPLS
drafts would contain such a applicability statement concerning the
level of IPv6 support.
I.e. 'IPv4 only', 'IPv4 + some IPv6' (like tunnels) or full IPv*
support (which would mean that all variants: 'IPv4 only' OR
'IPv4 + some IPv6' OR native 'IPv6 only' are possible with the
draft spec).

>    indicates that a label binding for this path is requested and also
... 

> "Label Request without Label Range
...
> RSVP extensions to transport IPv6.

Well ok, this confirms what I assumed after reading the draft. But
I rather wanted to point out that I see actually no reason not to
add the more or less minor(?) extensions needed for complete native
IPv6 support right now.
As far as I can see it - and perhaps I miss some implications - adding
basic but complete IPv6 support (i.e. find perhaps ways to map the IPv6
flow label etc. later) right now would not be such a big deal for most
of the drafts, wouldn't it?
I know all the arguments about IPv6 not needed in the cores right now
(if at all), no business case yet etc.etc. and I don't want get into this
here. But given that there were made already quite a number of provisions
for IPv6 in the drafts why not complete it for native IPv6?
As a starting point I've appended here a old message from April 1999
from David Mankins concerning IPv6 support in the TE-RSVP draft
(which suggests to add a C-type LSP_TUNNEL_IPv6 to support IPv6 tunnel
sender and egress addresses). Hope this is not obsolete for some
reason? And I guess chapter 2.1, 2.2 would need a little bit tuning
for IPv6 as well. But if I don't miss something these would be rather
minor changes in the draft - or not?

regards,
Thomas Wolfram

     -----snip-----
>
> From: [email-masked] [mailto:[email-masked]] on behalf of david mankins
> Sent: Monday, April 12, 1999 6:09 PM
> To: [email-masked]
> Subject: LSP_TUNNEL_IPv6 c-types are missing from draft-ietf-mpls-rsvp-tunnel-02
> 
> 
> 
> Bora Akyol mentioned this before the latest draft of the document came
> out, but The document should specify the C-type LSP_TUNNEL_IPv6 (for
> all the classes that have C-type LSP_TUNNEL_IPv4) before it becomes a
> standard.
> 
> In particular, 
> 
>       Class = SESSION, C-Type = LSP_TUNNEL_IPv4 (7)
> 
>        0                   1                   2                   3
>       |                   IPv4 tunnel end point address               |
>       |  Must be zero                 |      Tunnel ID                |
>       |                       Extended Tunnel ID                      |
> should probably have an ipv6 equivalent:
> 
>       Class = SESSION, C-Type = LSP_TUNNEL_IPv6 (?)
> 
>        0                   1                   2                   3
>       |                   IPv6 tunnel end point address               |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |  Must be zero                 |      Tunnel ID                |
>       |                       Extended Tunnel ID                      |
>       |	                      Extended Tunnel ID (cont'd)   
>           |
>       |                       Extended Tunnel ID (cont'd)             |
>       |                       Extended Tunnel ID (cont'd)             |
> and:
>       Class = SENDER_TEMPLATE, C-Type = LSP_TUNNEL_IPv4 (7)
> 
>        0                   1                   2                   3
>       |                   IPv4 tunnel sender address                  |
>       |  Must be zero                 |            LSP ID             |
> should have a corresponding:
> 
>       Class = SENDER_TEMPLATE, C-Type = LSP_TUNNEL_IPv6 (?)
> 
>        0                   1                   2                   3
>       |                   IPv6 tunnel sender address                  |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |  Must be zero                 |            LSP ID             |
> and, 
>       Class = FILTER SPECIFICATION, C-Type = LSP_TUNNEL_IPv4 (7)
> 
>        0                   1                   2                   3
>       |                   IPv4 tunnel sender address                  |
>       |  Must be zero                 |            LSP ID             |
> should have a corresponding
> 
>       Class = FILTER SPECIFICATION, C-Type = LSP_TUNNEL_IPv6 (7)
> 
>        0                   1                   2                   3
>       |                   IPv6 tunnel sender address                  |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |                   IPv6 tunnel sender address (cont'd)         |
>       |  Must be zero                 |            LSP ID             |
> - david mankins ([email-masked], [email-masked], phone(US): 617-873-2873)
> 
     -----snip-----