Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Shane,

Please see inline,

> So, please tell me how I'm supposed to ping/traceroute to this 32-bit
"Router
> ID" in this new IPv6-only world, just like I do today in IPv4 today,
to verify
> reachability?  

Good question. We should be pinging/tracerouting peer's Transport
address or TCP connection address, not Router ID. This is similar to
what we typically do with OSPF, for ex.

I am pasting the sample show command output (from Cisco and Juniper
routers) to better illustrate this (notice ^^^^^^). While the output
shows IPv4 transport address since the session is LDPoIPv4, it would be
an IPv6 addresses if the session was LDPoIPv6.  

//
JUNIPER ROUTER
=============
user@host> show ldp neighbor extensive
...
   Transport address: 10.255.245.5, Configuration sequence: 6
   ^^^^^^^^^^^^^^^^^^^^^^^^
..
//

CISCO ROUTER
============
RP/0/RP0/CPU0:router# show mpls ldp neighbor  
  
  Peer LDP Identifier: 10.44.44.44:0
    TCP connection: 10.44.44.44:65535 - 10.33.33.33:646
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Graceful Restart: No
    State: Oper; Msgs sent/rcvd: 49/46
    Up time: 00:33:33
    LDP Discovery Sources: 
      POS 0/1/0/0
...
//

> Usually, this is one of the first steps in troubleshooting a
> problem.  I'm curious if we've gotten lazy by assuming dual-stack v4 +
v6 will
> "always be there", so I can just use v4 to ping/traceroute to a 32-bit
Router ID

Not at all. In fact, we continue to consider IPv6-only (which will exist
for long long time) and add the relevant/missing pieces to accommodate
dual-stack (which will disappear sooner or later) while thinking about
IPv6 LDP. 

Again, the router ID is a 32-bit quantity, whether it is used for IPv6
BGP, or IPv6 OSPF or IPv6 LDP or all of them.


> FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically,
a
> protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire;
> however, "out-of-band" I assign a IPv4-mapped IPv6 address to a
Loopback
> interface on a router and inject it into my "IPv6-only" IGP in order
to
> preserve my ability to see it in the topology (in the routing table),
and
> simultaneously am able to ping/traceroute to it to ensure that the
Loopback
> interface is "alive".  But, this is a kludge, because now I have to
keep the
> ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address
on a
> Loopback interface ...

Aaah, I follow it now. Thanks for clarifying it. This could be a
reasonable option for a deployment, but certainly not pretty.    

Interestingly, there are few deployments that actually use the last
(non-zero) 32-bits of the assigned "IPv6 prefix" as the Router Id for
IPv6 BGP and IPv6 OSPF. This doesn't require any IPv4-mapped-IPv6
address usage and works reasonably well for consistency. This depends on
the addressing schema though.

Cheers,
Rajiv


> -----Original Message-----
> From: Shane Amante [mailto:[e-mail]]
> Sent: Friday, March 02, 2012 2:02 AM
> To: Rajiv Asati (rajiva)
> Cc: t.petch; Aissaoui, Mustapha (Mustapha); [e-mail]; Lizhong Jin
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> 
> Rajiv,
> 
> On Mar 1, 2012, at 11:02 PM, Rajiv Asati (rajiva) wrote:
> > Hi Shane,
> >
> > Thankfully, neither approaches are embraced/recommended/considered.
> >
> >> a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I
> > can
> >> transport IPv4 "Router ID's" around my network? Or,
> >
> > No.
> >
> > Router-ID is no longer a routable entity in IPv6 networks. Please
refer
> > to BGP (RFC6286) & OSPF (RFC5340).
> > In fact, OSPF (RFC5340) explicitly prohibits Router ID to be any
IPv6
> > address.
> >
> > BGP RFC6286
> > //
> >      The BGP Identifier is a 4-octet, unsigned, non-zero integer
that
> >      should be unique within an AS.  The value of the BGP Identifier
> > //
> >
> >
> > OSPF RFC5340
> > //
> >   o  OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the
> >      IPv4 size of 32 bits.  They can no longer be assigned as (IPv6)
> >      addresses.
> > //
> 
> Yes, I heard you before.  Thanks, got that.
> 
> So, please tell me how I'm supposed to ping/traceroute to this 32-bit
"Router
> ID" in this new IPv6-only world, just like I do today in IPv4 today,
to verify
> reachability?  Usually, this is one of the first steps in
troubleshooting a
> problem.  I'm curious if we've gotten lazy by assuming dual-stack v4 +
v6 will
> "always be there", so I can just use v4 to ping/traceroute to a 32-bit
Router ID
> ... but, what happens when v4 is no longer there any more?
> 
> 
> >> b) Will we have to settle for IPv4-mapped IPv6 addresses, just for
the
> >> purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the
> >> operational reasons I outlined in my previous e-mail?
> >
> > No.
> >
> > It wouldn't make any sense, nor would it help.
> > v4-mapped v6 address is still a v6 address, after all and it
wouldn't do
> > any good for 32-bit router-id.
> 
> FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically,
a
> protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire;
> however, "out-of-band" I assign a IPv4-mapped IPv6 address to a
Loopback
> interface on a router and inject it into my "IPv6-only" IGP in order
to
> preserve my ability to see it in the topology (in the routing table),
and
> simultaneously am able to ping/traceroute to it to ensure that the
Loopback
> interface is "alive".  But, this is a kludge, because now I have to
keep the
> ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address
on a
> Loopback interface ...
> 
> -shane