I'm considering a more general case, as in my previous note. I do't
see ULAs as a general case; they are a specific case of a larger
problem. And I think we should solve the multihomed case and let
single-homing be a special case of that. The point is that you have
some number of active prefixes (two in a single-attached domain, N+1
in a multihomed domain), and you want the prefixes distributed
correctly.
On Jan 13, 2010, at 7:51 AM, Ralph Droms wrote:
Fred - are you considering a multi-homed network or a network with
one edge router and at least one additional internal router?
- Ralph
On Jan 12, 2010, at 9:15 PM 1/12/10, Fred Baker wrote:
On Jan 12, 2010, at 11:09 PM, Ralph Droms wrote:
Fred - I disagree with:
If I have more than one router on a LAN and one is responding to
RS's with RAs, the others should not do so on that interface, but
should inherit their prefix from the router that is responding.
If the subscriber network is multihomed, with different prefixes
from different SPs, should each router advertise its own prefixes?
If I am a router that knows its address per DHCP, that takes
precedence over learning it from an RA.
What I'm talking aobut is the situation of "Home RTR" in figure 3
of http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation
on its interface facing CPE RTR ISP #1 and #2. I submit that from
each of the CPE routers, it should learn a prefix - because each of
those has a prefix already assigned. One could imagine it also
asking them what prefixes it should assign as prefix:2..prefix:7.
- Ralph
On Jan 12, 2010, at 4:09 PM 1/12/10, Fred Baker wrote:
I don't see anything in the RFC about the behavior of routers in
this context; in point of fact, I don't see anything about
routers coming up and finding each other. I would interpret that
as "routers are expected to be configured, manually or
dynamically, as opposed to determining prefixes and addresses
dynamically".
It seems to me that it is very rational to consider a router as
getting an address on an interface in three possible ways:
- manual configuration
- DHCP [RFC 3315]
- via a Router Advertisement from another router
manual configuration takes precedence over dynamic configuration,
and dynamic configuration over an RA. But if a router has neither
of the first two, then I would agree that on that interface it is
operating as a host until something changes that.
By that logic, it should send an RS, and with the resulting RA it
should configure itself with both a prefix for the interface and
an address within the LAN. Absent the prefix for the interface,
it would have to forward datagrams to the other router in order
to know they belonged on the local LAN. Having "inherited" that
configuration, if you will, there is something it should *not*
do: it should not issue an RA with that prefix while it is in
contact with said other router, as doing so is redundant. It
should only send RAs if it loses contact with the original router
advertising the prefix.
Note that this is suddenly not specific to ULAs; it is also true
of global addresses. If I have more than one router on a LAN and
one is responding to RS's with RAs, the others should not do so
on that interface, but should inherit their prefix from the
router that is responding.
On Jan 12, 2010, at 9:50 AM, Ole Troan wrote:
hi,
a question arose from work I'm doing with the BBF and their CPE
requirements document (TR-124/WT-192). an issue has been raised
with regards to a requirement about CPE routers automatically
offering ULA addresses on the LAN. in the case of multiple CPE
routers on a link, the suggestion is the following two
requirements:
LAN.ADDRESSv6. 3 The device MUST send a Router Solicitation to
the LAN, to determine if there
are other routers
present. MUST
LAN.ADDRESSv6. 4 If the device determines other routers are
present in the LAN, and that another
router is advertising
a ULA prefix, the device MUST be configurable to
automatically use
this information to decide not to advertise its own
ULA prefix. MUST
any opinion on these requirements and how they compare with
expected behavour as specified in RFC4861?
cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/
ipv6
--------------------------------------------------------------------
http://www.ipinc.net/IPv4.GIF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
http://www.ipinc.net/IPv4.GIF
http://www.ipinc.net/IPv4.GIF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
