Subject: Next-Hop in IPv6 only environment

From: Manav Bhatia <[email-masked]>
Date: Thu, 13 Feb 2003 14:36:19 +0530

Hello,
I have a very basic doubt in implementing BGP extensions for IPv6
Inter-Domain Routing.

Consider two routers (not running dual stack) as shown in the figure.

-----------                    --------------
|               |                    |                    |
|  peer 1   |    IPv6         |     peer2      |
|               | ------------ |                    |
|               |                    |                    |
-----------                   ---------------
  3ffe :: aa                         3ffe :: bb

They are peered up using IPv6 addresses using TCP over IPv6. Which is then
the IPv4 next-hop which shall be used in all the BGP UPDATE messages. Does
it need to be explicitly configured or is one of the global/local IPv6
addresses converted into IPv4 and used. How is it done?

In case of dual stack one can look into the interface over which the
peering takes place and use that IP address as the next-hop. But what
happens in case of IPv6 only?

Regards,
Manav

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 13 Feb 2003 18:18:17 +0530

Hi,
I guess in case of IPv6 only environment then one necessarily needs to
configure a Router ID which will be filled in the mandatory fields. But
then if the Router ID is non-routable then one cant advertise IPv4
reachability information using that peering !!!

Is this correct?

Regards,
Manav

---

From: Mareline Sheldon <[email-masked]>
Date: Thu, 13 Feb 2003 06:59:59 -0800 (PST)

Exactly.

If your network is IPv6 only then you must somehow give some IPv4 address which this router
may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI.

Mareline S.

> > happens in case of IPv6 only?

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Feb 2003 13:13:03 -0500

> may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI.

If the boxes, as shown below, are NOT running dual stack, then an
IPv4 nexthop is nonsense.  IPv4 reachability should be discarded.

-- 
Jeff Haas 
NextHop Technologies

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 14 Feb 2003 08:29:44 +0530

Jeff,
If you are not running a dual stack you still need an IPv4 address as a
next-hop (even though it wont be used) which will be used as a mandatory
path attribute along with the ORIGIN and AS-PATH.

--
Manav

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "Mareline Sheldon" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 13, 2003 11:43 PM
Subject: Re: Next-Hop in IPv6 only environment

> > > > They are peered up using IPv6 addresses using TCP over IPv6. Which
is
> > > then
> > > > the IPv4 next-hop which shall be used in all the BGP UPDATE
messages.
> > > Does

---

From: Enke Chen <[email-masked]>
Date: Thu, 13 Feb 2003 19:13:10 -0800

Hi, Manav:

> Date: Fri, 14 Feb 2003 08:29:44 +0530
> From: Manav Bhatia <[email-masked]>
> To: Jeffrey Haas <[email-masked]>,
> 	Mareline Sheldon <[email-masked]>
> Cc: [email-masked]
> Reply-To: Manav Bhatia <[email-masked]>
> Message-id: <[email-masked]>
> 
> Jeff,

This is not correct. As the nexthop value is carried in the MP_REACH_NLRI
filed, the NEXTHOP attribute is not needed at all. Please See the following
text from RFC 2858:

-------------------------------------------------------------------
2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):

   An UPDATE message that carries the MP_REACH_NLRI must also carry the
   ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP
   exchanges).  Moreover, in IBGP exchanges such a message must also
   carry the LOCAL_PREF attribute. If such a message is received from an
   external peer, the local system shall check whether the leftmost AS
   in the AS_PATH attribute is equal to the autonomous system number of
   the peer than sent the message. If that is not the case, the local
   system shall send the NOTIFICATION message with Error Code UPDATE
   Message Error, and the Error Subcode set to Malformed AS_PATH.
---------------------------------------------------------------------

-- Enke

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 14 Feb 2003 08:54:45 +0530

Enke,
Then why does the draft-ietf-idr-bgp4-18.txt still mention the NEXT_HOP
field as a well-known mandatory attribute. If it isn't required for some
extensions then i believe we must mention it somewhere.

Moreover, i have never come across any implementation which doesn't look
for this attribute when it receives an UPDATE message!

Regards,
Manav

----- Original Message -----
From: "Enke Chen" <[email-masked]>
To: "Manav Bhatia" <[email-masked]>
Cc: "Jeffrey Haas" <[email-masked]>; <[email-masked]>; "Mareline
Sheldon" <[email-masked]>; <[email-masked]>
Sent: Friday, February 14, 2003 8:43 AM
Subject: Re: Next-Hop in IPv6 only environment

> > > > may use as the next-hop when advertising BGP UPDATE messages. One
way
> > could be through CLI.
> > > > > I guess in case of IPv6 only environment then one necessarily
needs
> > to
> > > > > configure a Router ID which will be filled in the mandatory
fields.
> > But
> > > > > > it need to be explicitly configured or is one of the
global/local
> > IPv6
> > > > > > In case of dual stack one can look into the interface over
which
> > the
> > > > > > peering takes place and use that IP address as the next-hop.
But
> > what

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Feb 2003 22:37:26 -0500

> extensions then i believe we must mention it somewhere.

The general idea is that this is the basic specification.  The extensions
alter the base specification.

I'm not fond of our current mechanism for doing this since it will
lead potentially to a base specification with a higher RFC number than
the extensions which would lead to similar confusion that you are having.

However, I'm also not fond of the idea of trying to do all of the
extensions and the base spec in one document.  If I suggested such a
thing, I expect that Yakov would nail my hide to an IBM DASD chassis
as a warning to all others and Sue would gleefully seize all of my
office supplies.

-- 
Jeff Haas 
NextHop Technologies

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 14 Feb 2003 09:16:31 +0530

Jeff,

> the extensions which would lead to similar confusion that you are having.

I believe that adding a small pointer in the base spec is much better than
having others spend cycles trying to understand the apparent contradiction
in the base spec and the extensions. A small note saying that this is not
necessarily true anymore or something like that can very easily be
accomodated for greater clarity and perspecuity of the RFC.

> extensions and the base spec in one document.

I agree.

> If I suggested such a

And the IDR community will also loose a very good reviewer :-)

Regards
--
Manav Bhatia
Samsung Electronics.

---

From: Enke Chen <[email-masked]>
Date: Thu, 13 Feb 2003 20:43:24 -0800

Manav,

> Date: Fri, 14 Feb 2003 09:16:31 +0530
> To: Jeffrey Haas <[email-masked]>
> Cc: [email-masked]
> Message-id: <[email-masked]>
> 
> Jeff,
> 

Reading RFC 2858 again, it actually has the explicit text on the NEXT_HOP
attribute:

   An UPDATE message that carries no NLRI, other than the one encoded in
   the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
   If such a message contains the NEXT_HOP attribute, the BGP speaker
   that receives the message should ignore this attribute.

-- Enke

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 14 Feb 2003 10:28:55 +0530

Enke,

>    that receives the message should ignore this attribute.

Yes it indeed is.

However it would be really nice if a similar thing is mentioned somewhere
in the base spec too OR once again, a pointer to the fact that NEXT_HOP
attribute is not always *mandatory* is mentioned to remove any later
confusions amongst the implementers.

I have a gut feeling that this issue will crop up again some time later
down the line. The confusion will be all the more aggravated when your base
spec RFC is greater than your extensions RFC nos.

Thanks,
Manav

P.S.
Once again, the issue isn't that RFC 2858 isn't clear .. its just that it
defies what the base spec mandates any implementation to do!

It just gets all the more skewed when the base spec is more recent than the
extensions draft/RFC!
:-)

---

From: [email-masked]
Date: Sat, 22 Feb 2003 15:28:04 -0800

Going through the entire base spec and adding a caveat in every place where
an extention document modifies it, is almost as much work as documenting all the
varriant behavior in the base spec.  

If there is confusion on this issue, I would suggest we add a statement
like this:

 This document specifies the base behavior of the BGP protocol.  This
 behavior can and is modified by extention specifications.  When the
 protocol is extended the new behavior is fully documented in the
 extention specifications.

to the beginning of the document somewhere.

Andrew

On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Date: Fri, 14 Feb 2003 10:28:55 +0530
> To: Enke Chen <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>, [email-masked], [email-masked]
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> X-Mailer: Microsoft Outlook Express 6.00.2720.3000
> X-Priority: 3
> X-MSMail-priority: Normal
> Precedence: bulk
> X-Spam-Status: No, hits=0.1 required=5.0
> 	tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,
> 	      USER_AGENT_OE
> 	version=2.43
> X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5]
> 
> Enke,
>

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 24 Feb 2003 08:33:31 +0530

Yes .. this sounds nice .. and takes care of whatever extensions we might
put in some time later ..

Manav
----- Original Message -----
From: <[email-masked]>
To: "Manav Bhatia" <[email-masked]>
Cc: "Enke Chen" <[email-masked]>; "Jeffrey Haas" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, February 23, 2003 4:58 AM
Subject: Re: Next-Hop in IPv6 only environment