Ralph,
I couldn't agree with you more. I don't like entangling prefix
information with address assignment. It is so IPv4 thinking. I am off
this discussion now since I don't believe in any IPv6 network that
deploys DHCPv6 without a router or deployment where the router does
not
send RA's.
Further, I don't believe in sending prefix information that includes
prefixes other than those associated with assigned addresses, just
like
I don't believe in any IPv6 network deployed without a router. A host
can just receive prefix length and then host knows from its assigned
address what is on-link for this host - I have assumed this host
hasn't
seen any RA because if the host does, then L-bit from RA has to be
combined with prefix length for on-link determination. Any other
prefix
will be off-link and let the host send non-link-local traffic to
default
router.
Hemant
-----Original Message-----
From: Ralph Droms (rdroms)
Sent: Friday, August 17, 2007 12:48 PM
To: IETF List IPv6 Mailing; [EMAIL PROTECTED]
Subject: [dhcwg] Re: RE:
Prefix information includes prefixes other than those associated with
assigned addresses, or the case when the prefix associated with the
address is not on link.
Admittedly, the latter case is less than useful without a default
router. But default router information might come from elsewhere.
Why are we discussing taking a step *backward* in entangling prefix
information with address assignment, when the separation of those two
not-necessarily-related functions is one of the things IPv6
actually got
right? Please step back from saving a couple of bits and think about
the abstractions.
- Ralph
On Aug 17, 2007, at Aug 17, 2007,12:38 PM, Hemant Singh ((shemant))
wrote:
Ralph,
What all information constitutes prefix information? If a node is
DHCPv6
enabled in a RA-absent network, why isn't just the prefix length
enough
for the node to make an on-link determination with? In comparison, a
node that is DHCPv6 enabled in a RA-present network uses prefix
length
and L bit together to make an on-link determination.
Thanks.
Hemant
-----Original Message-----
From: Ralph Droms (rdroms)
Sent: Friday, August 17, 2007 12:27 PM
Subject:
References:
<C6FE2907-79C0-4EB2-90AC-
[EMAIL PROTECTED]><7ECEF9368E169544B43882B
[EMAIL PROTECTED]
EXC-02.mgc.mentorg.com><8E296595B6471A4689555D
[EMAIL PROTECTED]><8C324AEB-292B-42E5-
A6B6-4
[EMAIL PROTECTED]><[EMAIL PROTECTED]><
F
DB
98139-14EE-4D5F-B96D-
[EMAIL PROTECTED]><[EMAIL PROTECTED]
argle.gargle.HOWL><[EMAIL PROTECTED]><18115.3756.371573.1
0
32
[EMAIL PROTECTED]><[EMAIL PROTECTED]><m1zm0reu44.wl
%jin
[EMAIL PROTECTED]><[EMAIL PROTECTED]
m
b-
rtp-20e.amer.cisco.com><[EMAIL PROTECTED]
m
<
[EMAIL PROTECTED]
rtp-20e.amer.cisco.com><870
6B8AE-001D-4403-
[EMAIL PROTECTED]><B00EDD615E3C5344B0FFCBA910C
[EMAIL PROTECTED]
rtp-20e.amer.cisco.com><39C363776A4E8C4A94691D2BD9D1C9
[EMAIL PROTECTED]
NW-7V2.nw.nos.boeing.com><B00EDD615E3C5344B0FFCBA910CF7E1
[EMAIL PROTECTED]> <18117.50055
[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[EMAIL PROTECTED]>
Cc: "James Carlson" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
"Templin, Fred L" <[EMAIL PROTECTED]>, Iljitsch van Beijnum
<[EMAIL PROTECTED]>, ipv6@ietf.org, JINMEI Tatuya / ????
<[EMAIL PROTECTED]>
Content-Transfer-Encoding: 7bit
From: Ralph Droms <[EMAIL PROTECTED]>
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6
Date: Fri, 17 Aug 2007 12:27:46 -0400
To: "Hemant Singh (shemant)" <[EMAIL PROTECTED]>
X-Mailer: Apple Mail (2.752.2)
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 17 Aug 2007 16:26:47.0602 (UTC)
FILETIME=[685A1920:01C7E0EB]
Send prefix information, not prefix lengths with assigned addresses.
The little bit of savings in assuming the tie-in between assigned
addresses and on-link prefixes is short-sighted.
- Ralph
On Aug 17, 2007, at Aug 17, 2007,12:23 PM, Hemant Singh (shemant)
wrote:
Thanks, James. I agree with Fred then that a node can try DHCPv6.
But
now how does the node get a prefix length? As you are saying, some
manual or static configuration can be used. I certainly don't like
the
host to assume any prefix length in this scenario. Since I am not a
fan of any manual configuration, it does make sense, only for such a
case of absence of an RA, that DHCPv6 provides prefix length. Since
DHCPv6 doesn't know if the network's router will issue RA's or not,
then
DHCPv6
has to provide prefix length all the time.
Then I am for what Iljitsch is saying. If a host see a
discrepancy in
prefix lengths from RA and DHCPv6, then host has to decide based
on a
union of information.
Hemant
-----Original Message-----
From: James Carlson [mailto:[EMAIL PROTECTED]
Sent: Friday, August 17, 2007 11:49 AM
To: Hemant Singh (shemant)
Cc: Templin, Fred L; Iljitsch van Beijnum; [EMAIL PROTECTED];
ipv6@ietf.org; JINMEI Tatuya / ????
Subject: RE: [dhcwg] Re: prefix length determination for DHCPv6
Hemant Singh (shemant) writes:
I have not found any information in the ND RFC's nor DHCPv6 RFC
that
say a node can initiate DHCPv6 if node doesn't receive any RA. I
need
to see explicit text in some document to accept what you said
below.
It does say this. See RFC 2462 section 4:
The next phase of autoconfiguration involves obtaining a Router
Advertisement or determining that no routers are present. If
routers
are present, they will send Router Advertisements that specify
what
sort of autoconfiguration a host should do. If no routers are
present, stateful autoconfiguration should be invoked.
And then more forcefully in 5.5.2:
5.5.2. Absence of Router Advertisements
If a link has no routers, a host MUST attempt to use stateful
autoconfiguration to obtain addresses and other configuration
information. An implementation MAY provide a way to disable the
invocation of stateful autoconfiguration in this case, but the
default SHOULD be enabled. From the perspective of
autoconfiguration, a link has no routers if no Router
Advertisements
are received after having sent a small number of Router
Solicitations
as described in [DISCOVERY].
It's certainly pointless unless you also have access to some static
prefix information, but it's what the documents say to do.
--
James Carlson, Solaris Networking
<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442
2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
1677
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dhcwg
