[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
BGP4+ for IPv6
- Subject: BGP4+ for IPv6
- From: [email protected] (Francis Dupont)
- Date: Tue, 12 Dec 2000 06:44:07 +0100
- In-reply-to: Your message of Tue, 12 Dec 2000 12:54:50 +0900. <[email protected]>
In your previous mail you wrote:
> we need to put link-local address into nexthop field in IPv6 routing
> table (like kernel routing table in BSD). so:
> - A will consult IGP routing table, understands that C is behind B,
> installs the following route:
> BGP route from C/prefixlen -> nexthop is B's linklocal
> (left leg)
>=> I agree but the gateway field of a kernel route is not the same
>than the next-hop attribute of BGP (perhaps this is why I can't see a
what i am saying is, we need some guideline/whatever to implementers
as to how to handle global address in nexthop attribute. i have seen
many implementations that put global address (found on nexthop
attribute) as is into the kernel routing table, which is not correct
=> I agree, the best way is to get the link-local address from the IGP
(including the "static" IGP :-), ie. the gateway will be taken from
the route to the iBGP peer. If no such route exists then the iBGP can't
work... then it must exist. If BGP routes are redistributed into the IGP
with a better precedence this issue disapears but the code should not
rely on this (ie. "synchronization" must be correctly implemented).
i'm not saying that "we need linklocal address in attribute, always"
=> we agree... I don't believe RFC2545 needs clarifications, in fact
the whole BGP4 with confederations, reflectors, IGP interactions, ...
needs clarifications but in the operation area (ie. an informational
RFC about BGP will be wellcome, IPv6 is not more complex, BGP is
simply impossible to really understand for the newbie :-).
PS: fortunately current IPv6 networks are simpler than IPv4 networks...