> On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
>
> > As I wrote in another e-mail, rather than giving over everything to
> > hosts, I think, giving hints for selecting addresses should be
> > reasonable, at least in some environments.
>
> I would very much favor having an icmp messag
> From: Ralph Droms <[EMAIL PROTECTED]>
> 1. Is the following text an accurate summary of the previous IETF
> consensus on the definition and use of M/O bits:
>
>The M/O flags indicate the availability of DHCPv6 service for
>address assignment and other configuration information,
>res
> From: Suresh Krishnan <[EMAIL PROTECTED]>
> If I add the word intermediate in the text in order to read
>
> " This document proposes that all IPv6 extension headers be encoded in
> a consistent TLV format so that it is possible for intermediate nodes
> to skip over unknown extension h
> From: Suresh Krishnan <[EMAIL PROTECTED]>
> Manfredi, Albert E wrote:
> >> " o Extension headers must be processed in any order they appear"
> >
> > Why isn't the wording in RFC 2460 even clearer? Quoting:
> >
> >Therefore, extension headers must
> >be processed strictly in the order
It's not difficult to find even home users with multiple ISP
links. Both ISP's send RA's with different prefixes (A=1).
Host sees now two default routers on link and will have multiple
global addresses. By current rules, host can use either router for
outgoing packets regardless of the selected s
> From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
> > Avoiding DAD doesn't sound like a good goal to me. It means that the
> > system _assumes_ that the rest of the world is perfect and never has
> > any problems.
>
> Let me rephrase: making DAD more efficient. If there's a DHCP server
> prese
> Yes, I expect address resolution to be done on PPP links, just as is
> described in 2461. I expect it to be done _regardless_ of the
> underlying link technology.
If link like PPP does not have link layer addresses, there is no point
in doing "address resolution". Nobody should require impleme
> Well, this is exactly the problem with host implementations we are
> concerned with. The prefix list is being populated with a prefix when
> the list should not be populated.
As an implementor IPv6 stack, I say that I had no problem
understanding the L & A bits in prefix announcements.
Just
Related to this topic, long time ago when the choices of
a) DAD only on link local, and not on other addresses derived
from the same id (legal on original RFC)
b) do DAD indivially on each address
were discussed, I preferred (a) (and still do), and proposed an
additional logic on hosts using (a
Hi,
Slightly off topic, but I'm trying to find something that would guide
how to map IPv6 (and also IPv4) over IEEE 802.15.3 link layer.
I only found 6lowpan for 802.15.4. Where is the same for 802.15.3?
--
Markku S
e join to solicited address group goes back-to-back with
duplicate address test -- same info in both packets essentially).
But, I was "shouted" down, so I don't oppose it either.
--
Markku Savela
IETF IPv6 working
>From draft...
However, some intermediate nodes such as firewalls, may need to
look at the transport layer header fields in order to make a
decision to allow or deny the packet. If new extension headers are
defined and the intermediate node is not aware of them, the
intermediate no
Is thread trying to say the IPv6 *headers* specified in the IPv6 RFC's
leave the byte order of the header fields unspecified? I never noticed
this omission as an implementor.
For payloads, the issue is moot, because IPv6 and IPv4 payloads and
upper layer headers are same (or should always be, eve
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
> <[EMAIL PROTECTED]>
> We should first note that the notion of "node local" scope was
> deprecated in RFC3513. But I suspect there is almost no difference in
> practice between (now deprecated) "node-local" and "link-local of
> From: Bob Hinden <[EMAIL PROTECTED]>
> Possibly, however from Section 2.5.3 "The Loopback Address" it says:
>
> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
> It may be used by a node to send an IPv6 packet to itself. It must
> not be assigned to any physica
> From: Kurt Erik Lindqvist <[EMAIL PROTECTED]>
> Sure. But I am more worried of creating ambiguity with what
> applications does when receiving IPv4 compatible addresses as source
> addresses. If we are replying to them, we have the-facto not actually
> deprecated them :-)
There are many othe
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL
> PROTECTED]>
>
> In fact, RFC2461 is already pretty clear that such a prefix MUST be
> ignored:
>
>If the sum of the prefix length and interface identifier length
>does not equal 128 bits, the Prefix Informa
> On Sat, 19 Feb 2005, Markku Savela wrote:
> > This would work just fine, if nodes on internal network take the RA
> > prefix length as is, and just trunctate their ID-parts from higher
> > ends (or they could just generate ID randomly). Throw away all this
> > sillyne
Sorry about somewhat OT content, but...
For some intended uses, NDproxy is awfully complex way of achieving a
result, which would much easier to do as follows:
1) ISP give /64
2) use internally longer prefix (68 or 72), reserve the one (based on
ID assigned to the ISP link) for the ISP link,
> From: Colm MacCarthaigh <[EMAIL PROTECTED]>
> Really the only remaining portability issue is the default behaviour of
> bind(::) (without any specific options set).
In Symbian OS API, see
http://www.symbian.com/developer/techlib/v70docs/SDL_v7.0/doc_source/reference/cpp/Tcpip/
Bind to "any
> From: Jeroen Massar <[EMAIL PROTECTED]>
> Thus that applications should be using multiple sockets, one
> for IPv4 and one for IPv6 and one for whatever follows.
I strongly object to this. There are other socket api's which don't
have the Unix inherited drawbacks. For such, the recommendation is
> From: Bill Sommerfeld <[EMAIL PROTECTED]>
>
> They should not be removed from a new version of the spec without a
> mention in the newer version about *why* they were removed.
They should not be removed. Implementations already support it,
removing would just create confusion. I don't see any
> I have a question about a router behavior.
> rfc2461 and 2461bis assume that
> the router can stop packet forwarding without disabling to send RA.
Perhaps, so that one could have a configuration with multiple routers, one
advertising only as default router, and no prefixes. And, another that
wo
> From: "Rajan Srivastava" <[EMAIL PROTECTED]>
> But if I have a PPPv6 client running at my home PC, I can't do ND.
> I will have to resort to a DHCPv6 client [implemented at my PC itself]!
> Or is there any alternative?
Uhh? IPv6 stack is perfectly capable of receiving RA with prefix
information
Minor detail correction...
> From: Greg Daley <[EMAIL PROTECTED]>
> Please also be aware there is no issue for default router selection
> on hosts, (which is what the IsRouter flag is for) since they never
> receive the RS in the first place.
IsRouter only implies router, but it does not need to
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
>conditions, just delaying Neighbor Solicitation would cause
>congestion by the MLD report messages. The congestion would then
>prevent MLD-snooping switches from working correctly, and, as a
>result, prevent Duplicate
> From: [EMAIL PROTECTED]
> [Please express your opinion. It is needed to make
> the informed decision.]
>
> Pekka raised a concern about the usability of one of the
> methods (section 2.2 (c)) to select the source address
> of the ICMPv3 packet. I want to know if anyone has
> implemented it
I would like to implement the above, but it is somewhat hard when
there is no assigned type code from IANA. What does it require for
IANA to assign a type code? (same goes with the preferred route
option).
In my view the router solicitation could be viewed as "service
solicitation", and in additio
I believe DHCP for IPv6 is totally incorrect direction. It's a
leftover dinosaur from IPv4 way of thinking.
The whole DHCP6 concept should not have been designed. Instead, the
effort should have gone to extend the standard IPv6 configuration
framework: neighbor discovery.
If configuration is need
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]>
> basically, you seem to argue for DIID (against) DAD. Though I agree
> that DIID vs DAD is somewhat controversial and there is surely a
> tradeoff between those two, I believe the wg consensus was we should
> hon
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]>
> So, I'd now like to propose a concrete change. The simplest way to
> implement the option would be to remove the second exception shown in
> Section 5.4 of RFC2462. That is, the revised text would be:
>
> 5.4 D
> From: Soliman Hesham <[EMAIL PROTECTED]>
> What should a node do upon reception of a prefix option with the prefix
> length set to a value >64?
...
> 4. Leave this field as is and design a mechanism that
> allows the host to form an address based on the
> length of the interface identifier (i.e
> From: Brian Haberman <[EMAIL PROTECTED]>
> Markku Savela wrote:
> >>From: Brian Haberman <[EMAIL PROTECTED]>
> >>>- desire to avoid packet storms upon booting many nodes simultaneously
> >>
> >>2710 accomplishes this by using message supp
> From: Brian Haberman <[EMAIL PROTECTED]>
> > - desire to avoid packet storms upon booting many nodes simultaneously
>
> 2710 accomplishes this by using message suppression. If a node hears a
> Report for the same group, it cancels the transmission of any pending
> Reports it has for the group
> To address the following issue for rfc2462bis:
>
> There is conflict with the Multicast Listener Discovery
> specification about random delay for the first packet. The address
> autoconfiguration requires a random delay for a DAD packet if it
> is the first packet from th
Wait a minute...
> Moreover, if the packets destination address is a unicast address,
> an ICMP Destination Unreachable message [4] with Code 2 ("beyond
> scope of source address") is sent to the source of the original
> packet. Note: Code 2, as defined in [4], had a different
>
Just invading this thread for short comment...
> IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon
> the receipt of a Router Advertisement with the 'O' flag set (see
> section 5.5.3 of RFC2462).
Why would there be a "MUST"? The O/M bits are just hints what the node
could do a
> From: Soliman Hesham <[EMAIL PROTECTED]>
> Does anyone know of a router implementation that sometimes does not
> advertise all options to save BW ?
The problem is not with single router. It's with multiple routers and
this change requiring them to be in synch and advertising complete set
of eac
> From: "JinHyeock Choi" <[EMAIL PROTECTED]>
> There are pro and con between them. For example, if an MN receives a complete
> RA which contains all the prefixes, it can form new CoA immediately. Whereas, if
> it receives a RA which contains LinkID but no prefixe, an additional RS/ RA
> exchan
> Suggested resolution:
>
> - Introduce a new code (1) in the router solicitation
> and advertisement. When a host sends an RS with code = 1
> it requests that the RA include all prefixses valid on
> that link. Similarly, when a router sends an RA with code=1
> it means that the RA includes all pr
Minor comment on comments..
> From: Pekka Savola <[EMAIL PROTECTED]>
> 4) I'm not sure whether I see the immediate need for the unique subnet
> multicast scope assignment, as below:
>
>Furthermore, to avoid the need to perform manual configuration in
>most cases, an implementation should
> Off the top of my head I know that RFC3493 needs to be updated since
> the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop
> count. I really do not understand what a hop count of 0 implies and
> why we should bother updating the RFCs.
Heh, yes. I too wondered about what I should do
42 matches
Mail list logo
