[email protected] wrote:
But things are different if we do
ipadm create-addr -prefixlen 24 link0/10.1.2.3
I think the version in the design doc has this a
ipadm create-addr -i link0 10.1.2.3/24
and the dhcp command is "create-dhcp", with the "create-v6addrs"
covering dhcpv6.
Yes, I just read the new version of the document and it is more
consistent on this point.
But it still leaves out the -i link0 for a delete-dhcp. Given that we
can't leave out -i link0 for a delete-address it would make sense to
have it consistently require -i. Thus the name space for <label> becomes
local to the interface name.
What is the name space for that name? By that I mean whether or not I can do
ipadm create-dhcp4 -i link0 default
ipadm create-dhcp6 -i link0 default
or whether that tells me the object called "default" already exists.
If you specified it as above, then "default" would be considered the label.
A label must be specified at all times.
That doesn't answer my question whether the create-dhcp6 above would fail.
Furthermore, if myhost.com resolves to >1 IPv4 addresses (or IPv6
addresses), does the above create a single address object with N
addresses in it?
I would expect that in both cases, it would only use the first address
unless additional flags like -f were specified..
if we use ping/traceroute behavior as the template here, then you'd have
to use "-a" to add all addresses.
When ping was designed the Internet was a lot smaller and multihomed
hosts was a rare thing.
Furthermore, DNS doesn't actually return an ordered list; it returns a
set of addresses. Thus picking the first isn't defined.
I can see two ways forward on that one:
1. Do not allow hostnames for create-addr at all.
that would be the simplest solution. I was looking at DNS as a simple
way of creating "labels" for static addresses.
2. Make a hostname lookup all the IPv4 and IPv6 addresses and create a
single object with all those addresses in it. I.e., not need for a -f.
But DNS could return unexpected records, right?
That is an argument for not relying on hostnames.
And having the -f
flag give you some control over this..
But the alternative is to require -f everywhere i.e. I would need it
with set-addrprop, delete-address, etc.
My high-order comment was that stateless and dhcpv6 are welded together
per the RFCs since DHCPv6 is triggered from the router advertisements.
We could potentially have an administrative override for this (some
customer has asked for it), but if we want the default to be
stateless+dhcpv6 (where the resulting address set is a function of how
the routers and DHCPv6 agents have been configured) it would make some
sense to have a create-ipv6.
right- we have this as create-v6addrs in the design doc (though
create-ipv6 is less typing :-))
And 'v6' will be undefined when tcpv6 or sshv6 ships; having "ipv6" is
more specific.
right.. I think we have this as
ipadm create-v6addrs [-T <token>] <label>
(we should return an error if the same token is created with different labels,
though the design doc does not spell this out)
I think a create-ipv6addrs is sufficient provided that we have to option
to add a "no-dhcpv6" or "no-stateless" address property down the road.
(Perhaps we also want to force dhcpv6 even if the RAs don't say to do
DHCPv6.) But we probably need to be able to set those properties before
in.ndpd/dhcpagent sees the newly created address object and starts
acquiring addresses.
In summary, the fundamental questions I have above are around
1. making sure the name of the created object is clear for all the ways
they can be created
2. we need to decide how to handle the fact that IPv6 stateless and
DHCPv6 are welded together in the RFCs
We have this under create-v6addrs, and dhcpv6 can be disabled as
a address property. Maybe we should also allow the setting of this
property as part of the create-v6addrs (so that we don't have a window
where the dhcpv6 address is available and then disabled)?
I could have saved on typing if I had read the whole email before typing
the response...
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
