' > 2) s/The URI contains an IPv4 compatible IPv6 address/The > URI contains an > IPv4-mapped address/ in the header, or change u=.
=> I believe this should be 'IPv4-mapped' > > 3) IMO, it's a bit questionable to use IPv4-mapped > addresses like this > anyway. IPv4-mapped addresses should only be used (apart > from e.g. SIIT > definition) as a node's internal representation for IPv4 > address; for > better compatibility, the node should use: > > u=http://10.2.12.126/marsII > => But this does not look like an IPv6 address for an IPv6-only node. The SIIT case you mentioned above is an example where this would not work. > (this way the receiving IPv6 node can decide the mechanism > to reach the > IPv4-address; that is, if u= can contain either IPv4 or > IPv6 address) => The 'network' must give an indication of the mechanism to be used. If you use NAT-PT then you'll always see IPv6 addresses, if you use SIIT then you will see the mapped addresses, which will dictate certain actions by the IPv6-only device. If the device is dual stacked, the network will still give the indication of whether: - IPv4 only is allowed. - IPv6 only are allowed. - Both IP stacks are alowed. This is implicit from, say: - the knowledge you receive from your default router - Whether you can get an address (similar to the point above) and other indications. So the point is, a host can't just decide in isolation about what mechanism has to be used, it needs indications from the network, and that is why presenting the address as a mapped address is needed. Hesham > > Also: > --8<-- > IP6-multicast = hexpart [ ":" IP4-multicast ] > "/" ttl [ "/" integer ] > ; IPv6 address starting with FF00 > --8<-- > > 1) 'ttl' is not defined anywhere? (rather obvious though); > (_TTL_ is not > defined in IPv6 anyway, though.) > > 2) IPv6-multicast address does not need to start with FF00; > anything > beginning with FF is syntactically ok. > > 3) The full list of ABNF notations could be split to "normative" and > "informative" (e.g. of the latter, in this context, > IP4-address, b1, b4, > perhaps others), but that's a matter of opinion/clarity I guess. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
