Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 18 Mar 2014 20:30:23 +0000

Hi Mark,

> In the future, when the majority of new ISP's will be IPv6
> single stack, I don't foresee this practice stopping. There
> is sufficient RFC 1918 space for operators to use in order
> uniquely deploy Router-ID's across their backbone.

I wonder whether using RFC 1918 space would be needed, since the operators
have already had unique public IPv4 address space, which could continue to
be used (as usual) instead of private v4 space for the RID.

Nonetheless, this discussion could be somewhat more generalized (BGP,
OSPF, LDP, RSVP..) and brought up to the area WG mailer.

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: Mark Tinka <[email-masked]>
Organization: SEACOM
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, February 19, 2014 at 9:17 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>
Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt

>On Wednesday, February 19, 2014 07:47:26 PM George, Wes
>wrote:
>
>> WG] There¹s a related discussion happening in IDR/v6ops
>> right now
>> (https://mailarchive.ietf.org/arch/search/?q=BGP+Identif
>> ier&qdr=w&f_list=id r&gbt=1 starting 14 Feb) responding
>> to a proposal to make BGP Router ID a 128 bit field
>> because of the lack of direct mapping between the 32 bit
>> field and a potentially 128 bit address on an IPv6-only
>> device. So far, there has been significant feedback from
>> operators that in the case where these are simply fields
>> that contain an arbitrary 32 bit value whose only
>> requirement is that it is unique across some scope, we
>> need to be clear that the link between that field¹s
>> value and any particular IPv4 address is merely by
>> convention, not by protocol necessity, and therefore the
>> solution in an IPv6-only network may simply be to note
>> that in order for this to work, the operator must have a
>> method to derive a unique value, either
>> manually/programmatically assigned at provisioning time,
>> or via some sort of mapping from an IPv6 address present
>> on the box. I¹m inclined to handle this potential gap in
>> the same way, since the problem and discussion in IDR is
>> in no way specific to BGP, but I think it¹s something
>> that we need to discuss in this specific context - I.e.
>> does it break anything if the value is arbitrary and not
>> linked to an IP address present on the device?
>
>As you point out, today, operators have considered Router-
>ID's (be they for BGP or other routing protocols enabled on
>a router) as an arbitrary 32-bit integer that looks like an
>IPv4 address, but really isn't treated as one.
>
>In IPv6-only networks, today's routers still require a 32-
>bit Router-ID, and general practice is to hard-code this
>into deployments for BGP and other routing protocols
>(especially for single stack IPv6 routers).
>
>In the future, when the majority of new ISP's will be IPv6
>single stack, I don't foresee this practice stopping. There
>is sufficient RFC 1918 space for operators to use in order
>uniquely deploy Router-ID's across their backbone.
>
>Having said that, I could foresee issues where different
>single stack IPv6 routing domains interconnect, and there is
>the potential for Router-ID clashing if sourced from RFC
>1918 space. This could have an impact on the BGP Route
>Selection algorithm and/or setup and maintenance of BGP
>sessions. In this case, having a 128-bit Router-ID might be
>a sure-fire simple way to guarantee Router-ID uniqueness
>across inter-domain routing.
>
>The other option would be for both routing domains to pre-
>agree on Router-ID's that do not clash, but this adds
>complexity to both intra- and inter-domain routing.
>
>Mark.

---

From: Mark Tinka <[email-masked]>
Date: Thu, 20 Mar 2014 14:46:35 +0200

On Tuesday, March 18, 2014 10:30:23 PM Rajiv Asati (rajiva) 
wrote:

> I wonder whether using RFC 1918 space would be needed,
> since the operators have already had unique public IPv4
> address space, which could continue to be used (as
> usual) instead of private v4 space for the RID.

I am referring to new ISP's who launch services long after 
the RIR's don't have IPv4 space anymore.

In such a case, RFC 1918 is the only option for such ISP's, 
since they will have been really new on the scene.

It is also not completely unreasonable to assume existing 
operators who have fully assigned all their IPv4 allocations 
will either recover public IPv4 from dual-stacked equipment 
to use as Router-ID's, or also consider RFC 1918 to continue 
growing the IPv6 single-stack network.

Mark.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 21 Mar 2014 02:10:52 +0000

Hi Mark,

I see your point and somewhat agree to it.

IMO, given the the unique RID requirement being limited inside the
network, using RFC 1918 (or for that matter, any arbitrary 4-octet string)
would suffice in an IPv6-only network.

-----Original Message-----
From: Mark Tinka <[email-masked]>
Organization: SEACOM
Reply-To: <[email-masked]>
Date: Thursday, March 20, 2014 at 8:46 AM
To: Rajiv Asati <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt