Subject: [MMUSIC] RE: Last Call: Support for IPv6 in SDP to Proposed Standard

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 29 Jan 2002 18:50:24 +0100

'  > 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-masked]
  > --------------------------------------------------------------------
  > 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2002 20:17:23 +0200 (EET)

> mentioned above is an example where this 

See below.

>   > IPv4-address; that is, if u= can contain either IPv4 or 

I'll restate this: this depends on the definition of u=.

If 'u' can have:
 1) only IPv6 addresses, using mapped address is fine
 2) either iPv6 or IPv4 address, IMO IPv4 should be used when _sending_ 
the packet

We're arguing about point 2).  My point is that if address can be either,
some nodes [a dual stack] can receive values with u=[ipv4] _anyway_, and
must be able to cope with them.

> certain actions by the IPv6-only device. 
[snip rest]

Yeah, but the draft isn't about what the packet will look like after it
has been mangled by NAT-PT or SIIT -- what should be best when sent by
some node.  It's clear that if an IPv6-only node sees a packet, u= must be
an IPv6 address of _some_ form (if it's supposed to be reachable).