On Thu, 23 Oct 2003, Myung-Ki Shin wrote:
[...]
As Erik said, I think that this draft has benefits over unicast-prefix for
scope =2.
Each node can allocate group ID (32 bits) independently (without any user
input, without a fear of collision or any additional mechanisms).
There
I haven't been on this list very long so I'm unaware of the reasons to
revisit 2461 and I don't know whether the following issue has been
discussed, but:
Why is there no mechanism to learn DNS addresses through router
advertisements?
It is currently possible to attach a host to a link with
I haven't been on this list very long so I'm unaware of the
reasons to
revisit 2461 and I don't know whether the following issue has been
discussed, but:
Why is there no mechanism to learn DNS addresses through router
advertisements?
It is currently possible to attach a
Hello
This issue was discussed at the dnsop wg in vienna
and is still work in progress...
You can touch with below draft related this issue.
http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery
-00.txt
Related drafts
DHCPv6 allows for DNS configuration in hosts among other things.
Please don't definitely say that. As I said, RA based DNS discovery
is work in progress.
Hesham's statement does not reject RA-based DNS discovery, it
seems to me. there's nothing wrong with the above-quoted
the assumption made in RFC2461 is that the link MTU is constant
over the link, i guess. i don't think it is necessary to make
MTU negotiable between peers, it would complicate too many things.
What would it complicate?
Obviously nobody is going to force anyone to implement
Hello itojun
Hesham's statement does not reject RA-based DNS discovery, it
seems to me. there's nothing wrong with the above-quoted line.
Yes, I didn't say something was wrong but considered one of
issue.
Regards
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics
Iljitsch, I agree. This has been discussed a lot on the dnsop list...
there is currently no consensus about DHCPv6(Lite) vs RA-based discovery.
It will be interesting to see what the Moonv6 work may have to say in this
area, as the issue I'm sure will have been encountered there. There are
On Thu, 23 Oct 2003, Jun-ichiro itojun Hagino wrote:
[...]
the assumption made in RFC2461 is that the link MTU is constant
over the link, i guess. i don't think it is necessary to make
MTU negotiable between peers, it would complicate too many things.
FWIW, I agree with this
Please send substantive comments to the ipv6 mailing list, and minor
editorial comments to the authors. This last call period will end on 5
November 2003.
I do not believe that this document is ready for Proposed Standard.
My comments (both as suggested text corrections and as more
substantive
I have a high-level question first; is the intent to do these updates
and recycle the document as a draft standard?
Or to try to move it to full standard?
If recycle at draft is the goal, are there documents (such as MIPv6)
which contain extensions to the packet formats which should be folded
Currently, routers can advertise an MTU for a link. That's nice. But
what we really need is a way for hosts to find out the MTU each
individual neighbor can handle. 100 Mbps and slower ethernet interfaces
can typically handle only the standard 1500 byte ethernet MTU, while
gigabit
On Thu, Oct 23, 2003 at 08:39:37 +0100, Tim Chown wrote:
Iljitsch, I agree. This has been discussed a lot on the dnsop list...
there is currently no consensus about DHCPv6(Lite) vs RA-based discovery.
This keeps popping up and we don't seem to be converging. Just before
reading this thread I
On Thu, Oct 23, 2003 at 11:40:29AM +0200, Ronald van der Pol wrote:
On Thu, Oct 23, 2003 at 08:39:37 +0100, Tim Chown wrote:
Iljitsch, I agree. This has been discussed a lot on the dnsop list...
there is currently no consensus about DHCPv6(Lite) vs RA-based discovery.
This keeps
Hi,
Could we drop this thread here? :-)
IMHO, it's no use to try chase down this particular rathole in *this*
working group as well.
Just state that the discovery/configuration of DNS is outside of the scope
of this specification. Additions can be defined separately in DNSOP or
other WGs if
On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
[...]
See http://sd.wareonearth.com/~phil/net/jumbo/ for some links
surrounding this issue.
Yes, and...?
Even if you don't want a separate physical infrastructure, defining a VLAN
is trivial.
Really, I can't see all that many scenarios where
The Cisco IOS DHCPv6 server does both stateless DHCP and PD. The two
functions can be configured independently, so stateless DHCP can be
configured with just a couple of CLI commands. Of course, the PD code is
still in the IOS footprint...
The primary problem at this point is deploy a client in
On 23 okt 2003, at 11:08, Erik Nordmark wrote:
[Having hosts discover and use a larger than standard MTU between them]
This might be useful when the L2 doesn't have any MTU limitations.
For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16
bit length field (if I don't
Such a capability would enhance a layer 3 neighbor MTU management
capability, but it isn't required. Operators can simply have routers
annouce an upper limit on the MTU that may be used on a subnet. This
doesn't impede the best case scenario where all the switches support a
good sized
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Hierarchical Prefix Delegation Protocol
Author(s) : B. Kim, K. Lee, J. Park, H. Kim
Filename: draft-bykim-ipv6-hpd-00.txt
Pages : 12
Hi,
I think this is a very interesting document.
In fact, we have been working in something similar for some time, but still not
drafted it.
Our case is a very good example, because we are working in a project (www.6power.org)
that deploys IPv6 PLC networks. In our case,
we may have different
On Thu, 23 Oct 2003 11:03:12 +0100,
Tim Chown [EMAIL PROTECTED] said:
There seem to be a handful DHCPv6 implementations, but no stripped down
DHCPv6 Lite implementations yet (the Lite version not maintaining state
for IP leases etc).
I tried KAME's dhcp6[sc]. It seems to work. Don't
Yes, but we know very well that most of the (cheap) router/NAT manufacturers will not
implement 6to4 or any other IPv6 code until
there is market to make business, so meanwhile we need to take advantages of any
possible solutions.
Regards,
Jordi
- Original Message -
From: Juan
Hi,
In section 4.2 of RFC 2461 regarding the RA message format the following
is mentioned
Reserved A 6-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
The mobile-ipv6 draft
On 23 okt 2003, at 9:39, Tim Chown wrote:
It will be interesting to see what the Moonv6 work may have to say in
this area, as the issue I'm sure will have been encountered there.
There are still very few people working in networks where IPv6
transport DNS lookup is a requirement, hence this
A student in my IPv6 class this week made the comment regarding IPv6:
It seems like the paint isn't dry yet!
IPv6 needs stability and constant changes scare adopters away. I agree
DNS should be a component of RA's. But I feel strongly that we need to
stop making changes and show the industry
On Thu, 23 Oct 2003 10:18:12 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
I have a high-level question first; is the intent to do these updates
and recycle the document as a draft standard?
Or to try to move it to full standard?
= My understanding was that the new RFC would still
be in
The same would work also for ISATAP (see: isatap.com), except
that ISATAP can use any IPv6 prefix, i.e., not just 2002::/16.
(Besides; 2002 was *last* year...)
Fred
[EMAIL PROTECTED]
Tim Chown wrote:
Hi,
Yes, this will work. This technique is quite widely used, and is one
reason for this
-BEGIN PGP SIGNED MESSAGE-
Fred Templin wrote:
The same would work also for ISATAP (see: isatap.com), except
that ISATAP can use any IPv6 prefix, i.e., not just 2002::/16.
(Besides; 2002 was *last* year...)
They are talking about 6to4 (proto-41 :) which can use both
prefixes from
hi,
here is another issue. it involves both 2461 and 2462.
RFC 2461 says
Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY.
RFC 2462 says
If the Neighbor Solicitation is the first
30 matches
Mail list logo
