Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

[Masataka Ohta <[e-mail]>]

Stig;
 
> Yes, I also see cases where it wouldn't work. Unicast to relays
> have advantages, also wrt to security. Only issue is that server
> will need to know their addresses.

> Yes, relays should not have lists of clients. I'm not insisting
> on multicast in itself, but multicast is the only way I see to
> avoid having per client state.

Even if you use multicast, the addresses are necessary, anyway, to
confirm receipt of notification.

>>>Interesting question. It's relatively easy with standard
>>>PIM-SM. You only need to reconfigure the RP address on the
>>>routers, and if you use say BSR, you only need to change on
>>>the c-BSRs and c-RPs.
>>
>>It is more straight forward to change addresses of a DHCP server
>>on relayes to be used for unicast relaying. However, a DHCP server
>>is a single point of failure.

> I don't agree on this. And if you have multicast deployed, you
> will make sure that works as well.

BSR assumes that all the routers cooperate, which is not a case
when an ISP and its subscribers constitute a domain. There are
maliciousy or wrongly configured routers at subscribers.

It should also be noted that an RP with forwarding functionaliry
disabled may still announce its precense as an RP to a BSR, which
means there is no real robustness.

Intradomain multicast has its own area of application. However,
the area is a lot smaller than one might expect and does not
contain real robustness.

Other protocols should not simply expect the area satisfies
its requirement.

> But let's not
> discuss how to make multicast reliable here.

Just accept that it is not reliable.

>>Sure. However, mboned is the worst place to discuss "multicast
>>does not work at all".

> Well yes, people may not like it (; But there are people there
> that think that multicast could be improved.

That is the problem.

When I overturned their grand design on interdomain multicast
by proving that multicast routing table can not be aggregated
(distribution of receivers of adjacent TV channels is no
identical, so are of those of adjacent multicast addresses. See
my paper presented at INET'98 for furthere details), such
people tried to (and still trying, perhaps) *IMPROVE*
multicast to make the impossible possible.

> I would say that multicast and routing is in the network, while
> DHCP is an application making use of multicast and routing.

> DHCP may use site-scoped multicast if available, but it's not
> required.

It is required that all relay implimentations have code
supporting multicast, because no server addresses may be
configured.

Do you recognize that control traffic of interlink multicast is
often a lot lot more than that of applications like DHCP?

> However link-local multicast is required for IPv6 in
> general, also DHCP.

Link local multicast is a lot simper than interlink ones and just
works. Howvever, it works because broadcast works and broadcast
is just enough. Note, for example, that there is no IGMP snooping
on link local multicast that packets are broadcast to the entire
link. So, there is the amount of link bandwidht is same.

So, don't expect multicast too much.

Instead, I think it is necessary for DHCP WG to develop guideline
on robust relaying without relying on multicast.

For example, is the behaviour of relay with multiple unicast
addresses of servers specified somewhere?

					Masataka Ohta


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg