This is danger of going off topic I know (maybe it should go in v6ops),
but it's important to me to be able to understand the consequences of
the discussion, so please bear with me. It's definitely going to become
an operational FAQ, unless it is very clear whether/how a network
operator can force equivalent use of DHCPv4 static address assignment
for both source and destination addresses via DHCPv6 (possibly by
turning off SLAAC for assignment of GUA on an interface via a flag, or
via RFC3484 bis), and how to achieve this effect for all nodes on a
link, without resorting to local configuration. So I may as well the
first to ask.
Brian E Carpenter wrote:
Ray,
On 2011-05-31 08:05, Ray Hunter wrote:
...
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured on
the same link and with the same prefix, in the absence of a flag?
Whichever RFC3484bis or the local policy table determines;
this is orthogonal to the question of where the addresses come from.
Hmm. That's the conclusion I also came to myself already if there were
no flags.
So how would you prefer DHCPv6 (centrally) assigned addresses as opposed
to SLAAC EUI64 addresses derived from MAC BIA ?
Is this still an open issue, and I should just be patient?
Would you have to set a prefix for every single DHCP range in RFC3484,
and make sure the DHCPv6 assigned range did not overlap with likely
EUI64 derived addresses to be able to guarantee that the DHCPv6 assigned
address will be preferred?
Or would you have to double the amount of entries in the ACL for both
the DHCPv6 address and the SLAAC address (coded to MAC address)
Or will RFC3484 bis be updated to include this behavior by automatically
guessing which addresses are SLAAC addresses and which are DHCPv6
addresses and allow users to prefer DHCPv6 addresses?
Bearing in mind destination address selection is also affected, so it
might have to be able to remotely 'guess' what is a SLAAC address versus
a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is
no text today in version 02
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor
anything proposed to cover this case in emails]
see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html for
the last note.
> I'll send a query to the ipv6-ops list just to see if this is a
common expectation.
The answer to the operational question: Yes IMHO there is a very clear
operational expectation of being able to easily achieve DHCPv4 like
behavior using DHCPv6, and this is hot operational topic.
Some people have 50000 rules in their firewalls today. They won't thank
anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules that
may change every time a NIC card fails (SLAAC only).
Think
dynamic DNS too: which (destination) address(es) would be auto
registered at the server end?
Both, if it's a server and you've chosen to use dynamic address
allocation for servers. Again, this is orthogonal to where
the addresses come from. It's going to be SOP for servers with
multiple addresses.
<snip>
Yes, there are lots of bad habits that have grown up over the years
that IPv6 challenges. For example, setting the DSCP *as a function of
the source address* makes me cringe. We're going to have to get used to
the fact that IP addresses are not constants.
Brian
In the meantime, we have to continue to operate networks whilst
transitioning.
As I asked, regardless of whether we think it's good or bad practice, I
can assure you that it's certainly _common_ practice. Pretty much
everyone I know who implements MPLS DSCP based QoS networks does it via
IP based ACL's to overwrite DSCP on network ingress.
offtopic: on the longer term, please give us some alternatives to manage
and signal identities and QoS policies that are widely implemented by
all manufacturers and all network providers. No 2 MPLS networks I know
of use the same DSCP settings. Applications generally only set DSCP= EF
on voice traffic. Everything else you have no standard signaling
mechanism. It's rare for two OS'es to behave exactly the same way today.
Same with 2 applications. In the absence of anything better, people get
stuck on the lowest common denominator (IP address) and network ingress
re-writing.
Anyway for some operations it really isn't so bad: think of a few
traveling VIP users who need a bit better service without spending a
fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think
well managed server farm and private network where there's a bulk back
up server (all traffic placed in D3 class) next to an interactive
software licence in server (all traffic placed in D1 class) and the rest
of the traffic in D2. These guys are sometimes more worried about pure
performance and cost and ease of management, rather than theft of
service, re-writing apps etc. etc.
Not necessarily nice. But operational reality.
regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
